IRC log of #maemo-ssu for Sunday, 2012-11-18

*** arcean has joined #maemo-ssu00:03
*** dhbiker has quit IRC00:04
*** Skry has joined #maemo-ssu00:38
*** NIN101 has quit IRC00:42
*** NIN101 has joined #maemo-ssu00:42
*** dhbiker has joined #maemo-ssu00:56
*** trumee has quit IRC01:01
*** trumee has joined #maemo-ssu01:09
*** NIN101 has quit IRC01:50
*** LaoLang_cool has joined #maemo-ssu02:09
*** Sc0rpius has joined #maemo-ssu02:13
*** ron0062000 has joined #maemo-ssu02:36
*** ron0062000 has quit IRC02:45
*** LaoLang_cool has joined #maemo-ssu03:16
*** LaoLang_cool has quit IRC03:34
*** kolp has quit IRC03:39
*** LaoLang_cool has joined #maemo-ssu03:45
*** dhbiker has quit IRC03:57
*** nox- has quit IRC04:04
*** LaoLang_cool has quit IRC04:11
*** LaoLang_cool has joined #maemo-ssu04:19
*** arcean has quit IRC04:19
*** LaoLang_cool has quit IRC04:34
*** dhbiker has joined #maemo-ssu05:02
*** amiconn_ has joined #maemo-ssu05:26
*** amiconn has quit IRC05:26
*** amiconn_ is now known as amiconn05:26
*** DocScrutinizer05 has quit IRC06:04
*** DocScrutinizer05 has joined #maemo-ssu06:04
*** dhbiker has quit IRC06:25
Sc0rpiusheh06:42
*** dhbiker has joined #maemo-ssu06:46
*** chainsawbike has quit IRC07:39
*** chainsawbike has joined #maemo-ssu07:40
*** LaoLang_cool has joined #maemo-ssu09:43
*** LaoLang_cool has quit IRC09:45
*** MrPingu has quit IRC09:50
*** LaoLang_cool has joined #maemo-ssu09:51
*** Milhouse has quit IRC10:07
*** Milhouse has joined #maemo-ssu10:08
* freemangordon idle wonders why hildon-status-menu needs 6MB of heap10:20
jon_yfreemangordon: reserved in case it ever needs it without needing to call malloc :)10:25
freemangordonjon_y: well, all bins started as .launchers use enormous amounts of heap10:25
freemangordonthat could be normal, but still10:25
freemangordonI still don;t know what that maemo-launcher does :(10:26
jon_yit could do worst if you have read thedailyWTF10:31
keriofreemangordon: they inherit gtk from maemo-launcher10:54
kerioso it doesn't need to be loaded again10:54
freemangordonkerio: I understand what maemo-launcher/invoker does with gtk and why10:55
freemangordonthe point is that every .launcher uses a pile of heap10:56
freemangordonwhich should not be the case10:56
freemangordonthose ^^^ use at least 4MB, which makes no sense10:58
freemangordonesp for hildon-status-menu10:58
freemangordonthose 7-8 launcher programs use about 40-50 MB of heap, which is instane. Even if it is swapped10:59
freemangordon*insane10:59
keriowhat does that heap contain, i wonder11:00
freemangordonNFC how to check it11:00
keriogdb :D11:00
kerioor the source code11:00
freemangordonkerio: would you check heap size on your device?11:00
freemangordonfor hildon-status-menu11:01
kerioit's just maemo-invoker or something11:01
keriofreemangordon: sure, how do i check?11:01
freemangordonin/proc/../smaps11:01
kerioalso, which status-menu? :)11:01
freemangordonps| grep hildon-status-menu11:01
freemangordonthe second one is yours ;)11:01
freemangordonpid11:01
kerioso the one under maemo-launcher?11:01
keriothat's the real one i think11:02
freemangordonyep11:02
freemangordonyou'll get 2 pids11:02
freemangordonsecond one is what we need11:02
kerioholy shit smaps is huge11:02
freemangordonyes, it is11:02
keriowat do11:02
freemangordongrep -A 9 heap /proc/.../smaps11:03
keriok11:03
keriowhat do you need?11:03
freemangordonSize:11:03
keriooh11:03
kerio2984kB11:03
freemangordonmakes no sense11:04
freemangordonwhat is your uptime?11:04
keriowith pali's battery applet, cpumem-applet, flashlight, simple-brightness-applet and forcerotation11:04
kerio1 day 10:2511:04
freemangordonSize:               5780 kB11:04
keriohold on, did i boot at 11.30 pm then? :O11:04
keriowhy the hell did i do that11:04
keriooh right, charger confusion11:05
freemangordonwith flashlight and 2g/3g selection applet11:05
keriooh, i've got 2g/3g too11:05
keriofreemangordon: uptime?11:05
freemangordon1d 15h11:05
kerioi'll report back in 5 hours then :D11:06
freemangordonbut,but,... thats crazy!11:06
freemangordonwell, I have fmms too11:06
freemangordonwhich I think puts status menu applet too11:06
freemangordonbut again, I can't see a simple reason for such heap usage11:07
freemangordonand it is the same for all .launcer processes11:07
freemangordon*.launcher11:07
freemangordonthats fishy11:08
*** LaoLang_cool has quit IRC11:15
freemangordonhmm, it is not .launcher thingie, if compiled as a simple binary, hildon-status menu still uses  4952 kB11:37
*** MrPingu has joined #maemo-ssu11:39
*** NIN101 has joined #maemo-ssu11:52
freemangordonhmm, removing rtcom-notification-ui.desktop reduces heap usage by 3MB. WTF?!?11:53
freemangordonremoving rtcom-presence-ui.desktop saves 1MB more11:56
kerioneat!11:56
keriootoh, without the notification ui, you won't get notifications11:57
freemangordonI know, I was trying to find who uses such amount of memory11:57
keriohahaha, "Some of the more obscure uses of pivot_root() may quickly lead to insanity."12:00
kerioin the pivot_root(2) manpage12:01
*** M4rtinK has joined #maemo-ssu12:01
kerioin the BUGS section12:01
*** NIN101 has quit IRC12:19
*** iDont has joined #maemo-ssu12:26
*** iDont has quit IRC12:37
*** NIN101 has joined #maemo-ssu12:41
freemangordonThe fuck, osso-abook-home-applet is using 2100 KB12:53
jon_ythe address book?12:54
freemangordonno, home contact widget12:54
jon_yhuh, no idea why a link would use that much mem12:54
freemangordonwell, it uses osso-abook library12:55
freemangordonand I am starting to have the feeleing adress book is kept in memory for every osso-abook consumer12:55
freemangordonwhich would be insane12:55
jon_ya seperate copy for every consumer? :)12:55
freemangordonbut so far it seems that is the case12:56
freemangordonwell, not copy, but something like that12:56
freemangordoncache or who knows what12:56
freemangordonas  osso-abook-home-applet is 21k binary, which does not do much12:56
ShadowJKsilly coders thinking it'll be faster to load from swap than load from onenand ;)12:56
freemangordonShadowJK: this is heap12:57
jon_yShadowJK: nah their test case was a clean n90012:57
freemangordon2100K12:57
ShadowJKlocked in ram?12:57
freemangordondoes not matter12:57
jon_ymalloc(n*sizeof(entry))12:57
freemangordonthis is mallocked12:57
freemangordon*malloced12:57
ShadowJKso brk area?12:58
freemangordonmakes no difference if it is locked in ram or swapped, usig 2MB just to show avatar on desktop is insane12:58
jon_ylet me guess, osso-abook-home-applet is non-free12:58
freemangordonyou win12:58
jon_y:)12:58
freemangordonthe same for osso-abook12:59
jon_yvalgrind will be grinding12:59
ShadowJKYeah I just mean if they preloaded something they were silly thinking loading it from swap would be faster :)12:59
jon_ytoo bad they don't put debug symbols anywhere12:59
freemangordonShadowJK: look backscroll for hildon-status-menu heap usage12:59
freemangordonwoth and without rtcom-... plugins13:00
freemangordon*with13:00
freemangordonand those use osso-abook too13:00
jon_yso how much mem can I save if I redid the N900 UI with a basic X window without any themes? :)13:01
freemangordonso it is either osso-abook or underlying database13:01
ShadowJKhm, my hildon-status menu has 66M vmdata :)13:01
jon_yyep me too, crazy huge for some reason13:02
freemangordonjon_y: who know, 40-60 MB maybe13:02
jon_ysweet, an address book list that is an actual list UI element :)13:02
kerioShadowJK: mtdswap13:03
freemangordonjon_y: not sure I got your question, but I suspect that database is cached in memory for every process using it13:03
jon_yit would look like Win3.11, but it would save memory13:03
keriohow do you feel about it?13:03
freemangordonwhich is insane, given there is backend for that purpose13:04
jon_yfreemangordon: I mean redo the UI portion with a minimalist rewrite and got rid Nokia stuff13:04
ShadowJKAt the time I still had interest in harmatten and was going to read the sources for it, there were no sources13:04
freemangordonjon_y: we cannot get rid of address book13:04
freemangordonosso-abook?13:04
jon_yactually, I don't know too much of the backend, so I'm likely sprouting nonsense13:05
freemangordonjon_y: /usr/bin/osso-addressbook13:05
jon_ya reimplementation would take years, probably13:05
freemangordonwell, that could be done in a clever way13:06
freemangordonbut still not easy13:06
freemangordoni.e. a second backend keeping only one osso-abook instance for the system13:06
ShadowJKIf I'd make a cynical guess, sqlite was involved in backend and it became too slow so they load entire abook into everything? :)13:06
freemangordonShadowJK: afaik it is berkeley db13:07
jon_ylets put mysql in there instead :)13:07
jon_yor OracleDB if we have $$$$13:07
* ShadowJK stabs jon_y with a tusty fork13:08
freemangordonShadowJK: but you have a point here, it might be that abook loads libdb4.2, which caches everything in memory13:08
jon_yfeel the enterprise-ness13:08
freemangordonaah, why people don;t trust OS to cache the fs :(13:08
jon_yfreemangordon: does fork() call get involved in there?13:08
freemangordonjon_y: no13:08
ShadowJKjon_y; if we had 16 xeon cores and 128 gig ram and a raid-0 of Intel S3700 SSDs13:09
freemangordonI rebuilt hildon-status-menu withou .launcer stuff13:09
jon_yok, I was suspecting fork is duplicating the DB heap if something wrote to it13:09
freemangordonit still uses ~ 5MB13:09
ShadowJKbut these things usually slow even harddrives down to a crawl, and is about 1000 times worse on flash13:09
freemangordonjon_y: no, as exec follows fork13:09
jon_yok13:09
freemangordonbut removing librtcom... plugins reduces heap usage by $ MB13:10
freemangordon*4MB13:10
freemangordonyeah, libosso-abook-1.0.so.0 imports libdb-4.2.so13:11
freemangordonhmm, lemme check something13:11
*** kolp has joined #maemo-ssu13:15
freemangordonwell, seems like it is berkeley DB caching the data13:20
jon_yhow many instances are there?13:21
freemangordonthere is no instance13:21
freemangordonit is .so13:21
kerioShadowJK: srsly though, would mtdswap make it better?13:22
jon_yfreemangordon: I mean of the BDB cache13:22
freemangordonseems like every application using it has its own cache13:22
jon_yI would assume loading the .so means a heap for every client13:22
freemangordonlooks like13:23
jon_ythat would explain things13:23
freemangordonI wonder why it is not using mmap13:23
jon_ywindows developers?13:23
jon_yinterns?13:23
freemangordonoracle ;)13:23
jon_y:)13:23
jon_yI had to read through C code written by an CS intern once, it wasn't pretty13:24
ShadowJKkerio; make what better13:24
jon_yyou need GLIB to prevent memleaks?? you suck bad13:24
jon_yyou need that too to read directory entries and cat strings??13:25
kerioShadowJK: the N900 as a whole13:25
jon_ysurfice to say the code is now part of a critical infrastructure :(13:25
jon_yit's a blackbox that no one wants to touch13:26
ShadowJKkerio; i think the optimal algorithm for sd/mmc is same as for onenand, so if they've got good gc implemented in it I'd put that in normal swap algo13:26
kerioidk, mtdswap is apparently an actual thing13:27
kerioit's in mainline13:27
* ShadowJK wonders if N950/N9 has emmc that does more than 1-2 IOPS :)13:29
freemangordonhmm, seems heap can be disabled during build time. and maximum can be set at runtime13:29
jon_yfreemangordon: it still won't stop copies of caches per client13:30
freemangordonyes, but if we free 10MB, i'll be happy13:31
jon_yimho libdb-4.2.so should not be used directly by DB clients13:31
freemangordonwhy?13:31
jon_yexcept to talk to a singleton server instance13:31
freemangordonthere is no server13:31
jon_ythat would be the ideal case anyway13:31
freemangordonofc13:31
freemangordonbut there is no server13:32
jon_yyeah I know, which is kind of an architectural problem13:32
kerioShadowJK: wouldn't mtdswap wear out the flash pretty quickly, on the n900?13:34
* ShadowJK shrugs13:34
ShadowJKusing that tiny thing doesn't interest me much13:34
ShadowJKI'm waiting for my new microsd to arrive. It claims 100-150 iops random write.13:35
ShadowJKIf true performance is a tenth of that, it's still factor 5-10 improvement over every other microsd :)13:36
kerioShadowJK: are IOPS actually that important, compared to, say, random write speed?13:39
kerioShadowJK: also, the onenand will still be much faster in every regard13:43
ShadowJKiops IS random write speed13:48
keriohm, right13:50
keriohm, how would you measure the IOPS of a uSD?13:51
keriohow many writes of... how much?13:51
kerioin one second13:51
*** MrPingu has quit IRC14:07
ShadowJK4k random write14:20
kerioShadowJK: ...150 of those in one second? :O14:21
keriowhere is this marvel of technology14:21
kerioi wanna buy it14:21
jon_yfast, cheap, reliable, choose 1 :)14:24
kerioi know14:25
*** MrPingu has joined #maemo-ssu14:33
*** _shadowx has quit IRC15:19
*** M4rtinK has quit IRC15:36
*** andre__ has quit IRC15:39
DocScrutinizer05freemangordon: (hildon-status-menu 'heap usage') wait wait.... It's started via *.launch?15:44
DocScrutinizer05freemangordon: you say you know what launcher does, but I'm not convinced you do. launcher shares a memory region to all .launch'ed processes, so the per-process mem usage is largely bogus15:50
DocScrutinizer05so even a tiny process started as process.launch will show to have enormous amount of memory, but all of that memory is shared with all other .launched processes and thus the actual increase in RAM usage of whole system is *smaller* this way15:51
*** don_falcone has joined #maemo-ssu15:52
*** toxarisswe has joined #maemo-ssu15:53
don_falconehi, any1 seen luf lately?15:55
DocScrutinizer05~seen luf15:59
infobotluf <luf@nat/ibm/x-eeonivbxbcxtjtwl> was last seen on IRC in channel #maemo-ssu, 3d 15m 21s ago, saying: 'DocScrutinizer05: do you mean some alu plactic?'.15:59
DocScrutinizer05(.launch) it's basically same concept used for mce-plugins and (aiui) system-ui plugins16:02
*** toxarisswe has quit IRC16:02
don_falconedamn i hated those scripts already back in the days... *scratches head*16:06
kerioShadowJK: no srsly gimme a link for your magical uSD16:20
ShadowJKhttp://www.adata-group.com/index.php?action=product_feature&cid=7&piid=17816:25
ShadowJKhttp://www.adata-group.com/upload/ProductFeature/productImage3281.jpg :o16:25
*** don_falcone has quit IRC16:26
freemangordonDocScrutinizer05: for sure launcher does exec()16:26
freemangordonand that frees all malloc()-ed memory16:26
freemangordonalso there is no way (afaik) heap to be shared16:27
freemangordonDocScrutinizer05: but at the end it seems all that memory is used by addressbook16:28
freemangordonDocScrutinizer05: for example removing librtcom-... plugins from status menu (both use libosso-abook) reduces heap usage by 3-4 MB16:29
kerioShadowJK: hrmpf, i can't find an actual online seller16:29
*** MrPingu has quit IRC16:30
ShadowJKYou could have a launcher that loads common data into a format and data structures used by common apps, and you could fork and exec in a way that leaves that data around, and it'd be copy-on-write and shared between all the apps as long as they don't modify it16:31
DocScrutinizer05freemangordon: maybe I missed sth in prev convo, but I know ${randomprocess}.launch is basically a .so that gets loaded to main process16:31
DocScrutinizer05*one* main process16:31
DocScrutinizer05at least that's been the idea and description of what maemo-invoker does16:32
freemangordonShadowJK: as long as you do exec(), heap gets destroyed/freed16:33
kerioShadowJK: holy shit, a 32GB of those for 65 USD on amazon us16:34
freemangordonDocScrutinizer05: i've compiled hildon-status-menu with nolauncher option, memory usage remains the same16:34
DocScrutinizer05wee16:34
DocScrutinizer05well, obviously16:34
keriohahahahaha 92€ for the same one on amazon it16:34
freemangordonShadowJK: read long as soon :)16:35
DocScrutinizer05since it's just the one difference that with nolauncher, the memory isn't shared from maemo-invoker, but actually alloc'ed16:35
kerioShadowJK: hm, the description on amazon UK states "random write (IOPS) speeds are as high as 50"16:35
*** arcean has joined #maemo-ssu16:35
freemangordonDocScrutinizer05: in both cases memory is malloc()-ed16:36
freemangordonthe difference is that with .launcher you share GTK stuff16:36
freemangordon(ifusing GTK booster)16:36
DocScrutinizer05freemangordon: though... it should *not* allocate memory for stuff it doesn't use at all and that would get shared by maemo-invoker just because some other process pulled it in to shared memory pool16:37
freemangordonit does not16:37
freemangordonaiui maemo-launcher exploits copy-on-write16:37
freemangordoni.e. gtk relocations? is shared amongst all of the processes16:38
freemangordonor something like that16:38
freemangordonbut heap is not shared, that is for sure16:38
freemangordonanywa, high heap usage is not because of the .launcher, no matter what it does16:39
freemangordonDocScrutinizer05: for example contact widget process uses 2100KB of heap16:40
freemangordonand I can bet it is because it uses osso-abook16:40
freemangordonstill cannot understand who caches the whole db in memory - is it berkeley db, or EDS or NFC who16:41
jon_ycan't valgrind?16:42
freemangordonwon;t help16:42
freemangordonaiui16:42
freemangordonthis is not a memory leak, but inefficien memory usage16:43
jon_yhow about you inject/preload your .so to intercept malloc/free calls16:43
freemangordon^^^16:43
jon_yiirc valgrind can also intercept such calls16:43
freemangordonas ShadowJK pointed, that seems like a broken design16:43
jon_yyou could at least in theory tell were the heap alloc was called from16:44
freemangordonjon_y: sure, but how that will help, elaborate please.16:44
kerioeasy fix: don't make phone calls16:44
freemangordonwithout debug symbols?16:44
freemangordoni doubt16:44
freemangordonthere is a whole chain if closed source binaries16:45
jon_y.so mapping to tell where they come from?16:45
jon_ys/.so/.text/16:45
infobotjon_y meant: .text mapping to tell where they come from?16:45
freemangordondon't know what you mean16:45
freemangordonaaah16:45
freemangordongot it16:45
jon_yeach executable is loaded at a VM address, those malloc calls have to come from somewhere16:45
freemangordonyeah, yeah16:46
jon_yyou should be able to tell if the heap is owned by the GTk libs or BDB or whatever16:47
freemangordonwhat I cannot undersand is - BDB uses mmap, why it needs to cache in heap too?16:47
jon_yno idea, you found out the heap is owned by BDB?16:48
freemangordonno. but i suspect that16:48
jon_ytheir logic probably heap is faster than disk16:49
jon_ythough it runs afoul when you have very limited RAM16:49
freemangordonheap is almost the same as the size as log.0000001 file16:49
freemangordonin ~/.osso-abook/db16:49
jon_ysadly, you'll need to step into the BDB code to confirm the behavior16:51
freemangordonit is open source, so NP16:51
jon_yyeah, a debug version might come handy16:51
jon_yyou should also match the malloc calls to the free calls, to screen out temporary heap allocs16:52
freemangordonDocScrutinizer05: would you check what is the memory usage on your stock device of /usr/bin/osso-abook-home-applet16:52
* jon_y off to sleep now16:53
jon_ygood luck in your debug runs16:53
DocScrutinizer05hard to do on stock device. I can do on CSSU-T device16:54
freemangordon:(16:56
*** int_ua has joined #maemo-ssu16:56
*** MrPingu has joined #maemo-ssu16:56
freemangordoni'll ask on #maemo16:56
DocScrutinizer05how would cssu-t differ from stock in that regard?16:59
DocScrutinizer05or, if you prefer, I can do that on a "stock hildon" with KP46(?) system16:59
kerioDocScrutinizer05: why?17:00
keriostock has no /proc?17:00
kerio:o17:00
DocScrutinizer05- - - 14608  1528  1400    40   288     0     0     1  1980 user      20   1 S - - -  0:01.58  0.0  0.6 /usr/bin/mafw-playlist-daemon17:00
DocScrutinizer05- - -  VIRT   RES   SHR  CODE  DATA  LIB  DIRTY  PPID   PID USER     PRI  NI S - - -   TIME+  CPU% MEM% Command17:00
DocScrutinizer05kerio: what?17:01
freemangordonDocScrutinizer05: "stock" as "no CSSU"17:01
freemangordonjust in case17:01
keriowhy can't you check the memory occupation on a stock device?17:01
freemangordonDocScrutinizer05: and i need heap section in /proc/.../smaps17:02
DocScrutinizer05kerio: please reread, I never said anything like that17:02
freemangordonalnog with the size of /home/user/.osso-abook/db/log.000000000117:03
DocScrutinizer05I said I got no stock device. That's all17:03
freemangordon*along17:03
keriooic17:03
DocScrutinizer05freemangordon: maybe pasting the cmdline here would yield most exactly matching results to what you wanna see?17:04
freemangordongrep -A 9 heap /proc/`pidof osso-abook-home-applet`/smaps17:05
DocScrutinizer05since nobody (incl me, but for sure 'mere mortals' in #maemo) CBA to figure what your request translates to, in terms of cmdline incantation17:05
freemangordonDocScrutinizer05: ^^^17:06
DocScrutinizer0500016000-00298000 rw-p 00016000 00:00 0          [heap] Size:               2568 kB Rss:                 524 kB Pss:                 520 kB Shared_Clean:          4 kB Shared_Dirty:          0 kB Private_Clean:       148 kB Private_Dirty:       372 kB Referenced:          360 kB Swap:               2012 kB17:08
DocScrutinizer05grep -A 9 heap /proc/`pidof osso-abook-home-applet`/smaps|tr -d '\n'17:10
freemangordonyeah,  2568 kB17:13
DocScrutinizer05grep -A 9 heap /proc/`pidof osso-abook-home-applet`/smaps|tr '\n' '!'17:19
DocScrutinizer0500016000-00298000 rw-p 00016000 00:00 0          [heap]!Size:               2568 kB!Rss:                 516 kB!Pss:                 512 kB!Shared_Clean:          4 kB!Shared_Dirty:          0 kB!Private_Clean:       148 kB!Private_Dirty:       364 kB!Referenced:          296 kB!Swap:               2020 kB!17:19
DocScrutinizer052568 is not heap size17:20
freemangordon00016000-00223000 rw-p 00016000 00:00 0          [heap]!Size:               2100 kB!Rss:                1824 kB!Pss:                1808 kB!Shared_Clean:         16 kB!Shared_Dirty:          4 kB!Private_Clean:       336 kB!Private_Dirty:      1468 kB!Referenced:         1616 kB!Swap:                272 kB!17:20
freemangordonDocScrutinizer05: but?17:20
DocScrutinizer05just "Size"17:20
freemangordonwhat?!?17:20
freemangordonthe size: in [hep] section souns like heap size to me :P17:21
freemangordon*[heap]17:21
DocScrutinizer0500016000-00298000 rw-p 00016000 00:00 0          [heap]17:21
DocScrutinizer05heap section17:21
DocScrutinizer05Size:               2568 kB17:22
DocScrutinizer05size section?17:22
freemangordonDocScrutinizer05: you are trying to say this is not the total of malloc()-ed memory?17:23
DocScrutinizer05I'm not trying to say anything, probably17:24
DocScrutinizer05nm17:24
freemangordonok :)17:24
freemangordonwell, we can easily test that: int main(){ void * p = malloc(2048*1024); while(1) usleep(10000000);}17:26
DocScrutinizer05sorry, short on milk, thus no coffe yet here17:27
*** NIN101 has quit IRC17:27
DocScrutinizer05I can easily figure how some #include will pull in a shitload of buffers and stuff to every process using it17:30
*** NIN101 has joined #maemo-ssu17:30
DocScrutinizer05instantiate a object my-Abook17:31
DocScrutinizer05damage done17:31
DocScrutinizer05watch insane roaster shit17:31
DocScrutinizer05docs about abook are disgusting17:31
Lava_Crofthttp://img.gawkerassets.com/img/185owo0236jdvjpg/original.jpg17:33
DocScrutinizer05http://maemo.org/api_refs/5.0/5.0-final/libosso-abook/OssoABookAggregator.html#osso-abook-aggregator-find-contacts-for-phone-number  etc17:33
DocScrutinizer05see http://talk.maemo.org/showthread.php?t=60526&page=317:34
freemangordonwill do17:35
DocScrutinizer05actually http://talk.maemo.org/showpost.php?p=990571&postcount=1517:35
DocScrutinizer05Lava_Croft: epic fail17:38
Lava_Croftnot exactly epic, but very much fail17:39
DocScrutinizer05http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Using_Generic_Platform_Components/Using_Address_Book_API17:41
DocScrutinizer05( freemangordon ^^^)17:41
DocScrutinizer05for sure you don't want to use any of that bloated cruft to just get your own avatar picture17:45
DocScrutinizer05or sth silly as that17:45
*** M4rtinK has joined #maemo-ssu18:23
freemangordonDocScrutinizer05: why should I read the API docs?18:36
DocScrutinizer05not complete API docs, I just linked to it for giving an idea how much cruft there might come with touching any bit of libabook18:40
DocScrutinizer05freemangordon: actually I'd not recommend to anybody to read these API docs, since as I mentioned I think they're not exactly bearable18:42
freemangordonyeah18:42
kerioLava_Croft: haha18:42
kerioby the way, should i install nitdroid?18:43
*** int_ua has quit IRC18:46
* DocScrutinizer05 hands kerio a gun to shoot his own foot, for the better alternative to installing nitdroid18:50
kerioDocScrutinizer05: why? what's so bad about it?18:51
Lava_Croftthere's not really a reason to install android on a device which has an OS like Maemo18:54
Lava_Croftunless you like game X orso18:54
keriobut... dual booting!18:55
kerioit's fun!18:56
DocScrutinizer05~maemo-multiboot18:56
infobotmaemo-multiboot is probably deprecated, and a horrible hack.  PROBLEMS WITH NITDROID/MULTIBOOT? reflash rootfs&kernel aka COMBINED18:56
kerio>implying i'd use multiboot18:56
DocScrutinizer05kerio: your trolling today is extremely weak18:56
kerioseriously though, i feel somewhat insulted :<18:57
DocScrutinizer05my general notion that never changed: if you want andridiot, get a device that ships with this abomination. Those are cheap and modern and way more powerful than N90018:58
DocScrutinizer05nobody would want to run android on N900, why would you?18:59
kerioi wonder how to grab a partition out of an image of a block device that has a partition table19:27
kerioalso, why does the nemo image have an 8mb swap partition?19:30
Lava_CroftI like grown up people turning names of operating systems into 'hidden' insults19:33
DocScrutinizer05kerio: that's an illegal configuration. Partition table has to be in MBR aka block019:34
DocScrutinizer05of the physical device19:34
kerioDocScrutinizer05: i know, but doing dd if=/dev/sdb of=rawimg is convenient19:35
kerioand common19:35
DocScrutinizer05I love users delivering their critics/concerns wrapped into a loosely related statement about their moods, containing another wrapper of sarcasm, containing a 3rd wrapper of hard to even detect irony19:39
Lava_CroftI was being pretty serious19:40
*** FIQ|n900 has joined #maemo-ssu19:40
DocScrutinizer05so I'm pleased you enjoy my special humour19:40
Lava_Croftshort bus special,19:40
* kerio grabs some popcorn19:42
*** iDont has joined #maemo-ssu19:43
DocScrutinizer05kerio: sorry, i won't continue this futile "coversation"19:43
DocScrutinizer05kerio: If you wanna take over, utter something negative and use the letters "M$"19:45
DocScrutinizer05or the term windoze19:45
ShadowJKkerio; heh, I usually fdisk -lu when I image drives, so I can pick out partitions with offsets and loop device later if needed19:45
Lava_Croftm$ is a term that is not insulting at all19:46
Lava_Croftsince MS is a company and companies are all about $$$$19:46
Lava_CroftWindoze does not contain an insult either, its just bad spelling/bad slag19:46
Lava_Croftslang*19:46
DocScrutinizer05kerio: sorry, then. You see you have to come up with something better to make Lava_Croft like you better than me19:49
Lava_CroftQ_Q some more19:50
kerioWindows Visyou fucking cuntta19:50
Lava_CroftAnd people wonder why niches stay niches19:50
*** Skry has quit IRC19:58
*** FIQ|n900 has quit IRC20:23
*** FIQ|n900 has joined #maemo-ssu20:44
*** NIN101 has quit IRC20:55
*** NIN101 has joined #maemo-ssu21:02
*** FIQ has joined #maemo-ssu21:06
*** NIN101 has quit IRC21:12
*** NIN101 has joined #maemo-ssu21:16
*** MrPingu has quit IRC21:20
*** dhbiker has quit IRC21:38
*** arcean has quit IRC21:50
*** MrPingu has joined #maemo-ssu21:50
*** arcean has joined #maemo-ssu22:00
*** arcean has quit IRC22:15
*** arcean has joined #maemo-ssu22:20
*** arcean has quit IRC22:23
*** arcean has joined #maemo-ssu22:24
freemangordon~seen luf22:30
infobotluf <luf@nat/ibm/x-eeonivbxbcxtjtwl> was last seen on IRC in channel #maemo-ssu, 3d 6h 45m 59s ago, saying: 'DocScrutinizer05: do you mean some alu plactic?'.22:30
freemangordon:(22:30
kerio:(22:38
*** iDont has quit IRC22:41
*** arcean has quit IRC22:47
*** FIQ|n900 has quit IRC22:47
*** arcean has joined #maemo-ssu22:48
*** arcean has quit IRC23:05
*** trumee has quit IRC23:36
*** trumee has joined #maemo-ssu23:37
*** Jade has quit IRC23:49
*** Jade has joined #maemo-ssu23:52
*** Jade has joined #maemo-ssu23:52

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