**** BEGIN LOGGING AT Fri Dec 30 03:00:00 2016 Dec 30 08:02:49 hmm aaa123 is not anymore, but maybe his problem was kernel power reporting that "unexpected reboot detected. Custom kernel settings not loaded" Dec 30 08:03:00 is not here* Dec 30 13:06:20 DocScrutinizer05: nokia n900 has 4 GPIOs for eci Dec 30 13:06:35 at least they are named "eci" in stock nokia 2.6.28 kernel Dec 30 13:06:42 I know Dec 30 13:07:05 and there is configuration /* ECI INT#2 detect connected to mic/bias line */ which is never used Dec 30 13:07:27 when eci_sw1 and eci_sw2 are both set to zero Dec 30 13:17:25 current mainline kernel does not support that one button n900 headset... Dec 30 13:17:52 I will try to extend mainline rx51.c snd driver to support it Dec 30 13:27:43 ShadowJK: Pali: http://paste.opensuse.org/29295440 is a bq27200.sh (partial) log of a calibrate-bq27k.sh run. It's quite strange how the chip doesn't even adjust NAC anymore when it reaches 6% RSOC Dec 30 13:33:15 DocScrutinizer05, it hasn't reached the voltage threshold yet, which is at 3248mV, iirc. Dec 30 13:33:25 yep Dec 30 13:34:08 but that it doesn't count down even NAC is pretty strange, never realized that it works that way Dec 30 13:34:42 Yeah it holds it at 6% Dec 30 13:35:00 Eventually it does start counting down from 6% too, but I'm not sure what the conditions for that are Dec 30 13:35:48 EDV1 ? Dec 30 13:36:48 Might be if the "hidden" counter goes below 0% Dec 30 13:37:00 hmm Dec 30 13:37:27 although then it's probably also over the learning limit Dec 30 13:39:02 I *guess* when it really starts counting again then it does that on EDV1=1 and it counts down until 0% Dec 30 13:39:28 at EDVF it prolly will stall totaly Dec 30 13:42:22 internal counter (if such thing exists) must be way below 0% now: http://paste.opensuse.org/31660145 Dec 30 13:42:42 s/internal/hidden/ Dec 30 13:42:43 DocScrutinizer05 meant: hidden counter (if such thing exists) must be way below 0% now: http://paste.opensuse.org/31660145 Dec 30 13:45:25 I'm surprised about apparent health of that battery, I bought it "used" yesterday and it was flatbat, I suspect it sat in that carton box like that for years Dec 30 13:48:14 weird is how temperature of device is rising now that bat voltage drops a bit Dec 30 13:50:52 also current drawn from battery increased from avg 220mA to avg 300mA only by plugging in USB charger while charging *disabled* and 0.0mA drawn from charger Dec 30 13:51:13 yes, you need to wait for EDV1=1 Dec 30 13:51:34 I bet that's the damn MUSB core, plus ULPI, PHY etc Dec 30 13:51:54 Pali: I think we would need yet another input driver Dec 30 13:52:06 (re ECI) Dec 30 13:52:07 for snd? Dec 30 13:52:11 for eci Dec 30 13:52:47 isn;t it supposed to act like kbd? Dec 30 13:52:51 ECI would be hard to implement in state ready for upstream Dec 30 13:53:06 DocScrutinizer05 already did some investigation about ECI protocol Dec 30 13:53:37 but for that one button n900 headset either new input driver is needed, or integration into sound/soc/rx51.c Dec 30 13:54:00 I guess upstream will only accept input driver Dec 30 13:54:01 I will try to play with integration into rx51.c Dec 30 13:54:35 hmm, maybe I am missing something - why it should be integrated with snd? Dec 30 13:54:37 it needs functions from rx51.c, so either it will be in rx51.c or or rx51 exports funcions Dec 30 13:54:43 ah, I see Dec 30 13:55:00 also needed gpios are defined for rx51.c Dec 30 13:55:23 maybe rx51.c should create that input driver. I have no idea if upstream will accept that Dec 30 13:55:41 first I need some working code :-) and then I can modify it for upstream Dec 30 13:55:47 yeah :) Dec 30 13:56:02 Pali: do you have booting maemo with 4.9? Dec 30 13:56:12 no Dec 30 13:56:15 4.9 is broken Dec 30 13:56:21 oh Dec 30 13:56:27 CONFIG_CMDLINE is ignored Dec 30 13:56:37 and also cmdline from bootloader is ignored Dec 30 13:56:38 :D Dec 30 13:56:40 but there is a patch already? Dec 30 13:56:47 so no way to specify cmdline Dec 30 13:56:50 I saw on the ML Dec 30 13:57:02 there are more patches, but people discuss how to fix it properly Dec 30 13:57:07 ah Dec 30 13:57:37 basically CONFIG_CMDLINE was broken for arm since begining Dec 30 13:57:47 also cmdline from bootloader was broken for DT boot from begining Dec 30 13:57:58 and in some specific situation it worked :D Dec 30 13:58:16 yep, I read the discussion. But I was under the impression it was decided on how the fix should like Dec 30 13:58:16 some bugs where fixed and cmdline stopped working... Dec 30 13:58:30 *look like Dec 30 13:58:39 addin the missing node Dec 30 13:58:53 haha, looks like it is not simple Dec 30 13:59:00 and not enough for CONFIG_CMDLINE Dec 30 13:59:14 Pali: on the other hand - did you see the video with latest gtk3 h-d? Dec 30 13:59:24 not yet Dec 30 13:59:37 it is almost like the real one :D Dec 30 13:59:55 wanna link? Dec 30 14:00:00 y! Dec 30 14:00:12 just a minute Dec 30 14:08:18 (( ECI would be hard to implement in state ready for upstream)) then something is wrong with upstream Dec 30 14:12:15 DocScrutinizer05: I mean that we need to cleanup nokia's eci code from harmattan kernel Dec 30 14:12:22 cleanup will not be easy Dec 30 14:12:25 aah, yes Dec 30 14:12:51 *Nokia's code* may be hard to get upstream Dec 30 14:14:18 I wondered what might be wrong with upstream to not like ECI concept Dec 30 14:14:22 ;-) Dec 30 14:18:17 ShadowJK: http://paste.opensuse.org/17749468 http://paste.opensuse.org/73629256 Dec 30 14:18:32 Pali: http://46.249.74.23/allwinner/ Dec 30 14:18:48 the video from today, download it, do not try to play it in the browser Dec 30 14:19:07 for some reason FF doesn;t like videos recorded by n900 :) Dec 30 14:19:19 MoeIcenowy: ^^^ Dec 30 14:19:46 ShadowJK: LMD 1079 mAh -> Last Measured Discharge: 1264 mAh Dec 30 14:21:07 arcean: see the video ^^^ Dec 30 14:21:28 freemangodron: chromium also do not like it ;-) Dec 30 14:22:04 BTW Facebook doesn;t like n900 videos as well, there are some tags in the container Dec 30 14:22:20 something related to geolocation iirc Dec 30 14:26:19 ((for some reason FF doesn;t like videos recorded by n900 :))) VLC also acts silly Dec 30 14:29:38 hmm, seems my ISP is actually a good one - 2.5MB/s international upload, nice :) Dec 30 14:30:06 that's for ~5 euro per month Dec 30 14:30:47 so perfect ;-) Dec 30 14:31:02 freemangordon: please excuse my telepathic comment about your conenction Dec 30 14:31:19 hmm? :) Dec 30 14:31:35 my network connection for ~5 euro per month have even no public IP ;-) Dec 30 14:31:35 my dl bandwidth on that URL is ~700kB/s and thus only 3/4 of what's needed for streaming Dec 30 14:32:00 (although it comes with ipv6 Dec 30 14:33:02 DocScrutinizer05: well, there are more monkeys on the branch, so you don;t get the full bandwidth I guess Dec 30 14:33:13 fmg: not a bad price, external static ip too? Dec 30 14:33:28 ahm, no static Dec 30 14:33:36 not really static Dec 30 14:33:52 but it hasn't changed for the last couple of years Dec 30 14:33:57 :) Dec 30 14:34:20 well, avg speed now 912KiB/s, still too low for that video to live stream it Dec 30 14:34:26 P.S. I don't think current firefox is capable of being run on a 512MB RAM tablet for daily use Dec 30 14:34:36 it is not Dec 30 14:34:38 256MB RAM N900 will be even worse Dec 30 14:34:47 the video is like 3:03, download took >220s Dec 30 14:35:30 so VLC stopped playback and filled buffer every 10s Dec 30 14:36:11 maybe I should record in lower res next time Dec 30 14:36:32 yes... Dec 30 14:36:39 but when can we get the status menu? ;-) Dec 30 14:37:20 MoeIcenowy: I ordered 1GB tablet, got 512MB :). I opened it a couple of days ago - there are 2 empty places on the board - one for DRAM and one for FLASH chip :) Dec 30 14:37:33 MoeIcenowy: i dont think 1gb would be comfortable enough either ;) Dec 30 14:37:45 Yes Dec 30 14:37:56 we may need a special browser for 256MB RAM Dec 30 14:38:00 MoeIcenowy: accordin to android808, status menu should be working a bit, though I didn;t test it Dec 30 14:38:01 few days ago i was playing with self built droid on oppc Dec 30 14:38:03 opipc Dec 30 14:38:20 and caching things in mem would effect in oom kills Dec 30 14:38:30 the same goes for hildon-home Dec 30 14:38:56 freemangordon: nice progress! Dec 30 14:38:57 unfortunatelly web is memory hungry (big media) nowadays Dec 30 14:39:08 MoeIcenowy: besides n900, is there another device with 256? Dec 30 14:39:28 xes: ;) Dec 30 14:39:35 with ARMv7? I don't know any other with 256MB RAM Dec 30 14:39:51 although I have a WIP light-weight development board with 64MB ;-) Dec 30 14:40:07 BTW, dillo might have chance Dec 30 14:40:14 freemangordon: any plan to use a kernel patched with BFQ and MuQSS? Dec 30 14:40:21 we need dillo-touch ;-) Dec 30 14:40:28 but it still far from being ready Dec 30 14:41:14 xes: no. I don;t even know what MuQSS is :) Dec 30 14:41:46 anyway palemoon has some chance to be usable Dec 30 14:41:58 MoeIcenowy: that shouldn;t be that hard Dec 30 14:42:08 (offtopic) I wonder whether there's any binarys meaningful to run on a Wine on ARM Dec 30 14:42:11 once the engine itself is ready Dec 30 14:42:19 freemangordon: http://ck-hack.blogspot.com Dec 30 14:42:22 freemangordon: please don't mix physically implemented RAM with free memory Dec 30 14:42:47 DocScrutinizer05: hmm? in what regard? Dec 30 14:42:56 DocScrutinizer05: on modern Flash storages, even SD cards, are easily to be worn with swap Dec 30 14:43:02 IroN900:~# free Dec 30 14:43:04 total used free shared buffers cached Dec 30 14:43:05 Mem: 245540 240152 5388 0 20120 55696 Dec 30 14:43:25 DocScrutinizer05: so? Dec 30 14:43:54 so a browser doesn't have a 256MB of memory available on a 256MB RAM device Dec 30 14:43:59 sure Dec 30 14:44:05 sure Dec 30 14:44:10 we all known that ;-) Dec 30 14:44:25 it seemed like you're ignoring it though :-) Dec 30 14:44:40 I think it's a common sense ;-) Dec 30 14:45:09 going 256->512MB RAM on maemo means like a 10 times the amount of free memory available for browser Dec 30 14:45:22 DocScrutinizer05: yes, if it is microb Dec 30 14:45:46 if it is FF... makes no difference, it will still lack memory :) Dec 30 14:45:46 is it still possible to build a old browser on a new system? ;-) Dec 30 14:45:58 sure it is, but what's the point Dec 30 14:46:27 even on quad core old JS engine on microb will struggle Dec 30 14:47:51 anyone here with jolla phone? Dec 30 14:48:04 how's browser memory usage there? Dec 30 14:48:06 why? Dec 30 14:48:10 ^^^ Dec 30 14:48:17 nfc Dec 30 14:48:25 afaik it is qtmozembed Dec 30 14:48:53 that would give us a clue on how much can be stripped from gecko in terms of memory usage Dec 30 14:49:10 it seems I never managed to install a sshd on that device, so sorry I have no access to gather such info Dec 30 14:49:11 I mean - modern gecko Dec 30 14:50:08 tbh I didn't really touch jollaphone for years Dec 30 14:50:31 I'll ask on #jollamobile Dec 30 14:50:32 it's simply no nice experience to touch it Dec 30 14:50:38 :) Dec 30 14:51:49 and fuzzing around with a device I **need to send in for reflash** when I do a little oopsie?!??! really, no way Dec 30 14:52:50 what? you can;t flash it? Dec 30 14:52:53 no Dec 30 14:53:02 cuuute Dec 30 14:53:19 but,but... why? Dec 30 14:53:48 Jolla must not provide the sekrit sauce closed blob shit stored for snapdragon modem in the "private" partitions Dec 30 14:54:08 MoeIcenowy: do we have any chance for support on that gpu driver stuttering bug? Dec 30 14:54:25 ah Dec 30 14:54:45 * freemangordon wonders why they didn;t go for omap Dec 30 14:55:00 that's what you get from modem integration into SoC, where basicaly modem is DOM0 and linux is only a SOM-U Dec 30 14:55:06 DOM-U Dec 30 14:55:28 mhm Dec 30 14:55:40 FUUUUUBAAAAR Dec 30 14:56:18 only good for consumer products for sheep Dec 30 14:56:47 which alas was Nokia's and now is Jolla's approach to FOSS Dec 30 14:57:34 to then FOSS means you may use gcc to compile your apps, but sou have to keep your finger out of "THEIR" OS Dec 30 14:57:41 to them* Dec 30 14:58:14 started with Aegis, that stinking pile of shit Dec 30 14:59:09 and it's only a lucky coincidence that we didn't have Aegis on fremantle already Dec 30 14:59:22 looks like Dec 30 14:59:32 they always planned to go that path Dec 30 14:59:36 and that nolo can boot anything :-) Dec 30 14:59:44 just failed to implement it for fremantle Dec 30 15:00:21 Pali: that's an immanent part of such TC concept like Aegis Dec 30 15:00:49 bootloader only boots signed OS, and OS only grants certain permissions to any process Dec 30 15:00:52 well, on harmattan there is some thing called "open mode" afaik Dec 30 15:00:56 at least Dec 30 15:01:07 which locks your phone Dec 30 15:01:12 yep Dec 30 15:01:23 locks as in? Dec 30 15:01:36 nand is locked to read-only mode Dec 30 15:01:36 open mode actially means "secure element locked" mode Dec 30 15:01:44 bootloader and CAL Dec 30 15:02:07 and IIRC omap crypto HW too Dec 30 15:02:09 so you can't even change device lockcode Dec 30 15:02:19 I see Dec 30 15:02:25 Pali: yes, afaik that's correct Dec 30 15:02:51 but n900 has locked AES hw crypto too :-( Dec 30 15:03:07 Pali: not really, it is just not unlocked Dec 30 15:03:12 hmm, not sure about that Dec 30 15:03:26 or what freemangordon said Dec 30 15:03:27 locked == not unlocked Dec 30 15:03:42 this is rather a bug in nolo, than intentional Dec 30 15:03:50 :nod: Dec 30 15:03:55 and it can be done only in signed x-loader image Dec 30 15:04:12 Pali: maybe it is time to crack the keys ;) Dec 30 15:04:21 unless we got signing keys for x-loader aes remains locked Dec 30 15:04:34 cracking aes128? Dec 30 15:04:39 no, when it's not locked, it can get unlocked aby time until you lock the secure monitor or whatever the name Dec 30 15:04:47 bruteforce is slow Dec 30 15:05:02 afaik it is sha1, which is well, considered weak Dec 30 15:05:06 and I do not know any vulnerability in omap3 implementation Dec 30 15:05:09 why aes? Dec 30 15:05:10 as I understand it Dec 30 15:05:21 it is not encrypted, just signed Dec 30 15:05:33 I think I read somewhere there parts are encoded by aes128 Dec 30 15:05:46 hmm, no, afaik Dec 30 15:05:57 I do not remember details Dec 30 15:06:07 all the code is plain, you just hav a signature in the header, iirc Dec 30 15:06:16 but still, generating new valid sha1 signature is not fun! Dec 30 15:06:19 ~listvalues omappedia Dec 30 15:06:25 Factoid search of 'omappedia' by value returned no results. Dec 30 15:06:28 ~listvalues omapedia Dec 30 15:06:30 Factoid search of 'omapedia' by value returned no results. Dec 30 15:06:34 dang Dec 30 15:06:45 it was never documented on omapedia Dec 30 15:07:30 http://www.droid-developers.org/wiki/Booting_chain Dec 30 15:07:58 something is there: http://wiki.maemo.org/Firmware_hacking Dec 30 15:08:12 http://www.and-developers.com/custom_recovery:mbmloader_replacement_attack no idea if any of that is useful Dec 30 15:09:07 "Buy this domain." Dec 30 15:09:58 http://www.droid-developers.org/wiki/Cryptography Dec 30 15:10:57 Pali: yes, droid bootloader is crtypted, n900 is not Dec 30 15:11:20 just look in n900 flash images Dec 30 15:11:24 http://www.omappedia.org/wiki/Bootloader_Project Dec 30 15:11:30 nothing crypted there Dec 30 15:13:27 Note: If you are using an HS (High Security) OMAP device, an extra step is required. First, build x-load.bin using the steps above. Then, download the MShield signing tool and use the commands below. Contact your TI representative to get access to this tool. Dec 30 15:13:28 # cd mshield-dk-root-folder Dec 30 15:15:00 and this signs the image, most probably rsa signature with 1024bit key Dec 30 15:15:26 :nod: Dec 30 15:15:56 however it seems non-HS SoC don't need a common signature, they don't need *any* signature? Dec 30 15:16:21 so I assume they have a different core boot Dec 30 15:16:42 so, what we have (most probably) is sha1 hash signed wuth 1024bit key Dec 30 15:16:54 which should be close to be breakable Dec 30 15:17:02 *is* N900 a HS device? Dec 30 15:17:15 yes Dec 30 15:17:27 sorry, I am supposed to be the one to know, but... got headache Dec 30 15:18:40 just to note, nobody has found any colision in sha1 yet! Dec 30 15:19:34 freemangordon: isn't there a sort of "sealing" action executed during boot in xloader, which forbids further config changes to M-Shield? and is our xloader actually doing that sealing? Dec 30 15:20:23 DocScrutinizer05: x-loader is switching cpu to secure mode and then boot nolo Dec 30 15:20:52 once you switch to secure mode, it is not possible to switch back (only reboot or smc instruction) Dec 30 15:21:00 :nod: Dec 30 15:21:03 that's what I meant, yes Dec 30 15:21:18 and aes needs to be enabled in that x-loader code before switching... Dec 30 15:21:28 :nod: Dec 30 15:21:54 secure mode assigns AES hw accel to secure domain, while open mode it's available to userland Dec 30 15:21:59 afaik Dec 30 15:22:42 so AES accel is "only available on *non*-HS devices" Dec 30 15:23:29 while on HS devices (in HS mode) there's still crypto accel but only to monitor Dec 30 15:23:52 monitor aka smc Dec 30 15:24:11 the hw is always the same, I am pretty sure about that Dec 30 15:25:28 basically OMAP implements TZ/M-Shield as an additional addr line which only goes 1 when CPU in smc mode (from a sw exception) Dec 30 15:25:47 I read that TRM and via l3 or l4 firewall you can configure which address space you can access Dec 30 15:26:07 and it is configured to disallow access to aes address space Dec 30 15:26:18 and also disallow access to l3 or l4 firewall Dec 30 15:26:23 and you can config each hw IP block incl crypto to either have a "public" hw address or a secure domain (secure addr line = 1) hw addr Dec 30 15:26:40 yes, exactly Dec 30 15:27:03 and firewall is for n900 configured in way that you even cannot read current settings Dec 30 15:27:39 that TZ stuff is pretty versatile and seemingly implemented in a glitch free way Dec 30 15:27:44 I scanned address space and we have only unlocked sha1 and md5 crypto access Dec 30 15:28:19 Pali: what do you need that aes for? Dec 30 15:28:38 currently... nothing :-) Dec 30 15:28:38 iirc you can config firtually every page in RAM and NAND to be either secure domain or open domain Dec 30 15:29:09 I think l3 or l4 firewall will allows you to do that Dec 30 15:29:13 https://www.engadget.com/2010/03/09/1024-bit-rsa-encryption-cracked-by-carefully-starving-cpu-of-ele/ Dec 30 15:29:14 :) Dec 30 15:29:22 but only if you have unlocked firewall :D which is not on n900 Dec 30 15:29:25 really every shitty little timer can get configured if it's TZ secure or public Dec 30 15:30:41 there's a IP block called "mailbox", it's a multiple FIFO to exchange bytes (or words) between CPU cores. You can configure each single FIFO of mailbox to be secure or public Dec 30 15:31:46 ARM did a proper job with TZ Dec 30 15:33:45 but (like Aegis) the more versatile the stuff gets, the more complex it gets to correctly configure and set it up. And there *might* be bugs in sw doing the config Dec 30 15:34:27 first HARM Aegis policy versions allowed modprobe to load unsigned modules, or somesuch Dec 30 15:34:29 ;-P Dec 30 15:35:14 similar loopholes might exist in TZ/M-Shiled particular sw implementations Dec 30 15:35:52 I've tried to find ppa function that might allow us to tweak the FW, but failed Dec 30 15:36:06 I recall some hacker exploited a buffer overflow of sorts in a SMC function call Dec 30 15:36:09 yes, but there are two problems: 1) we do not have source code to look for bugs, 2) we even do not have binaries for all and we do not know all algorithms in use Dec 30 15:36:27 we have the binaries Dec 30 15:36:38 BTW, there is some sort of developer key afaik Dec 30 15:36:47 o.O Dec 30 15:37:07 and signing program for windows Dec 30 15:37:11 if we can only find it :) Dec 30 15:37:20 iirs that key is part of that signing program Dec 30 15:37:37 Pali: being windows is not a problem , you have wine nad WV after all Dec 30 15:37:45 *VM Dec 30 15:37:57 I doubt that dev key will work on n900 Dec 30 15:38:12 Pali: I remember something in CAl referenced it Dec 30 15:38:16 *CAL Dec 30 15:38:28 in CAL are some certificates and keys Dec 30 15:38:38 but I have no idea who uses them Dec 30 15:38:42 and how Dec 30 15:39:03 and, iirc, one of those is some developer key Dec 30 15:39:23 we can use to sign our own ppa, that is executed in secure mode Dec 30 15:40:05 CSST_SDP3430_v2_5_Binary_Release.zip Dec 30 15:40:25 it is that signing program Dec 30 15:40:27 yep, have it somewhere Dec 30 15:40:40 http://forum.gsmhosting.com/vbb/f83/nokia-rsa-private-key-195f111a9543a8644e77e1677296ab23-free-1490743/ Dec 30 15:40:43 you just need to load the correct keys Dec 30 15:42:09 hmm, might be a key for BB5 aiui Dec 30 15:42:28 well, BB5 also has an OMAP iirc Dec 30 15:42:35 not sure which, though Dec 30 15:43:06 ..an interesting document: https://www.uni-oldenburg.de/fileadmin/user_upload/informatik/ag/svs/download/thesis/Reichel_Sebastian.pdf Dec 30 15:43:40 easy to be checked, just calculate a signature with that key and compare it with modem firmware signature or nolo signature Dec 30 15:43:43 yes, I read sre's thesis Dec 30 15:53:03 it's a tad obsolete Dec 30 15:53:34 (thesis) Dec 30 15:54:45 DocScrutinizer05: we too :) Dec 30 15:54:51 hehe yes Dec 30 15:54:54 LOL Dec 30 15:56:46 maemo: kernel: custom - ummm Dec 30 15:57:06 (Table1.1 Dec 30 15:57:07 ) Dec 30 15:57:41 openmoko: kernel: custom - hell no Dec 30 15:58:28 maemo: userland software: GNU based - if only!! Dec 30 16:00:01 that's what basically *everybody* seems to get wrong (or *I* always got wrong after an intitial phase where I seem to got it right): maemo KERNEL is FOSS, maemo USERLAND is partially custom, see ~closed Dec 30 16:02:29 maybe by "custom" he means "not mainlined" (aka upstream?) Dec 30 16:03:11 but then, _who_ IS upstream? Dec 30 16:03:24 Linus? Dec 30 16:04:06 sounds pretty much like a moving phantom target Dec 30 16:06:12 it seems to me that large parts of IT experts have to more thoroughly adopt the concept/idea of 'middleware', and that a system consists of kernel - middleware/libs - apps Dec 30 16:07:46 what hurts most in fremantle are the closed middleware blobs, plus the lack of any proper interface/API and functional definitions/descriptions of that middleware Dec 30 16:08:34 there are a few closed blob apps too, but those would be easy to re-inplement in FOSS if only the middleware APIs would be available Dec 30 16:09:21 just like the middleware itself would be almost a nobrainer to re-implement if only those APIs... Dec 30 16:15:56 SpeedEvil had put it in a most precise way years ago, regarding the mess in maemo with that middleware. Alas I can't find the exact wording anymore, but it was like "it's _designed_ in a way to be everything entangled with everything, so you can't take out a single bit without making the whole thing collapse. And no docs at all just to the supposed purpose to ensure it stays like this" Dec 30 16:16:49 sounds like systemd description Dec 30 16:17:17 yes, it's very similar Dec 30 16:17:52 just fremantle isn't that monolithic Dec 30 16:18:20 well, actually systemd also isn't, but it *looks* even more like it was Dec 30 16:18:52 systemd is in one repository and they do not have defined stable api between components Dec 30 16:19:09 maemo has (or had) some stable api between components... Dec 30 16:19:14 neither did Nokia Dec 30 16:19:24 well, *some* Dec 30 16:19:54 many d-bus signals/msgs are not defined at all Dec 30 16:20:02 many libs are not defined either Dec 30 16:20:57 see the whole libisi and csd and whatnpt mess Dec 30 16:21:07 whatnot* Dec 30 16:21:24 ~closed Dec 30 16:21:25 extra, extra, read all about it, closed is http://wiki.maemo.org/Why_the_closed_packages or https://wiki.maemo.org/Fremantle_closed_packages, or http://elinux.org/N900 Dec 30 16:22:00 if there were decent APIs, all those closed blobs would be easy to FOSSify Dec 30 16:22:23 yes, some header files are missing... Dec 30 16:23:30 and a header file is no comprehensive API spec per se yet. A var int x34tz may be specified in .h yet you have no fucking clue how to use it Dec 30 16:33:40 who designed that maemo 5 architecture? Dec 30 16:34:07 when you have a int status, you need a enum 0: OK, 1: PIN error, 2: No signal etc Dec 30 16:34:20 Nokia and Colabora plus a few others Dec 30 16:38:42 and that is the root cause of a lot of problems with FOSSifying stuff it seems, since Colab must not publish source code they made for Nokia as subcontractor, and Nokia doesn't really have the copyright on the source either Dec 30 16:41:15 https://www.collabora.com/ Dec 30 16:44:03 https://www.collabora.com/industries/oem.html >> Hardware enablement --- Whether your products are intended to run on ARM or x86, there are always components that require particular attention. The Linux kernel has come a very long way however there is still (and will always be) a need for device drivers and general platform optimizations for your product to shine.<< Dec 30 16:44:42 and right they are Dec 30 16:45:35 thus I don't buy the "only mainline" approach, it won't yield optimum results Dec 30 16:46:09 and actually a generic mainline kernel is bloatware Dec 30 16:47:04 i think mainlining trick ensures that your driver/code wont stop working unexpectedly Dec 30 17:56:24 mv RSOC CSOC mA NAC CACD CACT TTF TTE TEMP Dec 30 17:56:47 18:54 4120 99 99 -19 1246 1246 1246 65535 3748 26 NOACT:0 IMIN:0 CI:0 CALIP:0 VDQ:1 EDV1:0 EDVF:0 Dec 30 17:57:51 3748 minutes time to empty not bad for roaming device with IRC online, eh? Dec 30 17:59:05 'roaming' = not on home WLAN Dec 30 18:22:43 just a quick hint. Telegram windows desktop ap seems to work fast. Messages appear on maemo pidgin and desktop about the same time. Dec 30 19:28:04 Vajb: that's Telegram's selling point .. they say speed :) Dec 30 19:28:27 >telegram Dec 30 19:28:34 please no Dec 30 20:28:07 sicelo-: it sure is fast. And works quite well so far. If only it would integrate as well as yappari. Dec 30 21:22:10 i should place a kickstarter to pay me for coding bits for maemo Dec 30 21:22:48 i had a plan for reusing yappari gui as frontend for a qt based telegram librar i found Dec 30 21:22:58 but tbh, i lost interest Dec 30 21:23:17 i even ended up buying an android phone :/ Dec 30 21:23:44 if i got paid to code for maemo i would leave this soul sucking job i have right now Dec 30 21:24:23 ceene: i'd settle for whatsapp web Dec 30 21:24:43 ༼ つ ◕_◕ ༽つ give whatsapp web client Dec 30 21:25:01 kerio: problem is the webapp communicates with the phone app, which is the one doing the communication with whatsapp servers Dec 30 21:25:07 yes Dec 30 21:25:17 i already have whatsapp running Dec 30 21:25:22 so web client means writing a client Dec 30 21:25:27 in android x86_64 Dec 30 21:25:30 on my server Dec 30 21:25:57 you could run web whatsapp on chromium Dec 30 21:26:15 or i could actually keep some ram for the rest of the phone Dec 30 21:26:20 but chrome/chromium on maemo is basically unusable due to low ram Dec 30 21:28:55 whatsapp is a strange IM server Dec 30 21:29:04 where you login by having the server scan a qr code with a webcam Dec 30 21:31:21 you can always vnc to your x86 android Dec 30 21:31:32 that's probably the less error prone way Dec 30 21:34:41