**** BEGIN LOGGING AT Fri Apr 04 02:59:59 2014 Apr 04 04:45:32 Maxdamantus: what will you be using your sms manager with? maemo? Apr 04 04:46:44 Sicelo: no. Apr 04 04:47:06 Sicelo: it won't be used with anything in particular. Apr 04 04:47:12 ok Apr 04 07:52:27 hmm, ofono Apr 04 07:52:46 you're aware of fso? Apr 04 07:53:00 ~fso Apr 04 07:53:01 i guess fso is the freesmartphone.org mobile devices middleware. http://www.freesmartphone.org// Apr 04 08:03:42 moin :) Apr 04 08:12:17 DocScrutinizer05: ofono seems more mature, and seems to serve a more precise purpose. Apr 04 08:56:39 Help: My Camera App hangs up at the 2nd Photograph… i have to kill it… what shall i do to resolve this Issue? Apr 04 08:57:01 It shows the Photograph before hanging Apr 04 08:57:05 And during Apr 04 09:35:17 Apic: I think it's because it's still busy saving the first photo. Apr 04 09:35:57 Apic: try mounting a tmpfs over the DCIM directory you're using. Apr 04 09:36:15 (to see if the problem goes away) Apr 04 09:36:34 Ok, mompls Apr 04 09:36:58 (it's not an actual solution, because they'd just be saved to memory) Apr 04 09:40:23 Yes, with the tmpfs i can save 2 in a Row… Apr 04 09:40:26 How to solve it? Apr 04 09:41:01 do you get the problem using the eMMC or an SD card? Apr 04 09:41:29 Internal eMMC Apr 04 09:41:51 Maybe the Firmware sees Bad Blocks and is continually resolving? Apr 04 09:43:22 Dunno. Apr 04 09:43:59 How big are the actual image files? Apr 04 09:44:37 Wonder if the camera application does a sync after writing the file. Apr 04 14:31:05 Maxdamantus: hmm, more mature? fso is older than ofono. precise purpose? that's a way to state what ofono initially blamed fso for "it's only an AT cmd interface - ofono will be more". seems now it's like exactly the opposite way and fso is the truly broad middleware and ofono the "AT interface" Apr 04 14:32:52 but yeah, ofono has the "more precise purpose" if you want to put it that way Apr 04 14:33:23 it doesn't have interfaces for an LED or a vibrator or a GPS thing etc Apr 04 14:33:40 afaik Apr 04 14:33:58 ie, it's a bunch of drivers for modems. Apr 04 14:34:35 Dunno. Does FSO have another advantage? Apr 04 14:39:43 ofono? right this might not have interfaces for LED and GPS Apr 04 14:40:38 FSO definitely has interfaces for all that Apr 04 14:42:29 the LEDs/vibrator are easy enough to control just using /sys. Apr 04 14:42:47 no Apr 04 14:43:16 the main idea behind fso is "dbus-driven" Apr 04 14:43:28 you can't even do that on maemo, you need to talk to mce for that Apr 04 14:43:28 you're missing this very point with /sys Apr 04 14:43:42 * Maxdamantus doesn't particularly like dbus. Apr 04 14:43:50 I don't either to be honest ;) Apr 04 14:43:59 I mean, I think something like dbus is important. Apr 04 14:44:10 nobody does, not even the original author of fso Apr 04 14:44:13 but I think dynamic filesystems already solved what dbus tries to. Apr 04 14:44:31 kind of like /sys, though that's not particularly neat either. Apr 04 14:46:52 * Maxdamantus wonders if cat-v lists dbus as harmful. Apr 04 14:47:03 because of 9p's precedent. Apr 04 14:47:13 :) Apr 04 14:47:40 It doesn't. Apr 04 14:48:04 anyway fso just resurrected from a 3 year baby-break of main developer, while ofono... dunno. Apr 04 14:48:25 ofono seems to have recent commits. Apr 04 14:48:32 it does Apr 04 14:48:32 wow Apr 04 14:48:55 Yeah, lots of commits this year. Apr 04 14:53:51 well, whatever. I prefer fso since it has the more educated and evolved middleware approach, while ofono really just focuses on modem and those guys never were any cooperative or welcoming Apr 04 14:54:19 of course it might also be I'm a little biased since I helped with FSO Apr 04 14:55:12 might be :) Apr 04 14:56:04 hmm do with have anything yet on neo900 modem btw ? any software plan ? Apr 04 14:56:13 but it's a really funny story that ofono guys, when micky suggested to them to join the new project to already existing FSO, blamed FSO to abe an "AT interface" and never answered again after that Apr 04 14:56:13 * Maxdamantus likes the modem driver approach better. Apr 04 14:56:58 * Maxdamantus doesn't run much under X on his computers other than xmonad, a web browser, mplayer, urxvt, mupdf and sonata. Apr 04 14:57:16 THEN you're actually better off with simple /sys and /day/ttyACM interfaces Apr 04 14:57:37 :)) Apr 04 14:57:55 with the N900 I'd like to run basically the same stuff (maybe not mplayer), plus some simple thing for SMS/calls. Apr 04 14:58:59 get the AT-cmdlist of 3GPP, it has all the needed AT cmds for SMS, to send over such /dev/ttyACM Apr 04 14:59:16 Heh. Apr 04 14:59:19 or - for silly maemo - pnatd Apr 04 15:00:00 wonder wether gammu would work out of the box Apr 04 15:00:40 sounds like the stuff in ofono/test Apr 04 15:00:55 which works out-of-the-box on Debian on the N900 Apr 04 15:02:48 I'll just write the main part around ofono first in Python, copying the dbus calls from test. Apr 04 15:03:13 then if I can be bothered, maybe I'll look into changing it to use /dev/ttyACM directly Apr 04 15:03:34 http://git.kernel.org/cgit/network/ofono/ofono.git/tree/test Apr 04 15:12:45 a pity that nobody understands the paramount importance of a proper middleware for embedded Apr 04 15:13:39 Nokia in maemo pushed for a frankenstein zoo of middleware-crippleware Apr 04 15:14:10 like liblocation, mce, mafw aso Apr 04 15:14:53 for some of them they opted for universal dbus interface, for others... not Apr 04 15:14:56 I feel like it would be more successful if there weren't "a middleware" Apr 04 15:15:18 just interfaces for various things. Apr 04 15:15:19 where "it" being what? Apr 04 15:15:47 so you have competition for the best GSM/whatever interface and so on. Apr 04 15:15:58 wut? Apr 04 15:16:31 all you get is competition between apps trying to concurrently use same GSM/whatever interface Apr 04 15:16:47 Temporarily. Apr 04 15:16:58 Then one will become dominant. Apr 04 15:16:58 meh Apr 04 15:17:21 you missed the point. *completely* Apr 04 15:17:25 Instead, company X will decide it doesn't like the way middleware Y handles feature Z. Apr 04 15:17:31 so they'll make a new one. Apr 04 15:18:07 I'm not talking about 2market", I talk about "runtime" Apr 04 15:18:08 Maxdamantus: you're talking about "competition", DocScrutinizer05 is talking about concurrency Apr 04 15:18:16 Linux, glibc, coreutils, Xorg .. typical combinations of software, none dependent on the other. Apr 04 15:19:01 Yes, I know. Apr 04 15:19:05 GSM, GPS, battery, terman management: typical subsystems NOT independent of each other Apr 04 15:19:15 thermal* Apr 04 15:19:51 I've been running `acpi -bi` on my laptop for years without GSM or GPS. Apr 04 15:20:39 again MEH Apr 04 15:20:58 I can see another interface in /sys for the N900's battery, which doesn't require GSM or GPS at least above the kernel level. Apr 04 15:20:58 since that tells me... you're missing the point Apr 04 15:21:27 *completely* Apr 04 15:22:59 good luck with controlling your vibrator device for realtime feedback in a game like 2maze" and then phone stack wants to use vibrator to signal inbound call concurrently Apr 04 15:23:56 with initiating a 911 call despite battery too hot for normal calls Apr 04 15:24:27 with using GPS when it's part of the modem actually Apr 04 15:24:59 with doing that from several concurrently running location-aware apps Apr 04 15:26:33 app A using your apecial curly to enable GSM to access GPS. Then app B does same, since you patched both to know about the mix of GSM and GPS. but when you stop app A, will it shut down GSM, or will it magically know about app B using GPS still? Apr 04 15:27:17 another thing about small interfaces is that they can easily be adapted. Apr 04 15:27:47 I haven't paid too much attention to the sound system wars in Linux, but I remember things like oss/arts/esd/alsa/pulseaudio probably other random stuff. Apr 04 15:27:58 you could usually adapt. Apr 04 15:28:17 sorry, I feel like this discussion is leading nowhere. we're speaking different languages or live on different planets Apr 04 15:28:19 there's a pulse output in alsa, there's an alsa output in pulse. Apr 04 15:28:29 Maybe. Apr 04 15:29:39 Maxdamantus: right, and it's a bit like when we had no alsa, plain oss with no muxer, and had to mux several apps Apr 04 15:29:59 there will prolly be a ofono adapter for GSM in FSO. There will not be any such thin in ofono to use FSO. But there might be a compatibility layer in FSO to allow ofono interface for apps to FSO GSM subclass Apr 04 15:30:17 either use one single app at a time, or use a sound system (pa, esd, whatever) on top of oss Apr 04 15:30:42 Most applications nowadays aren't limited to oss. Apr 04 15:30:54 * DocScrutinizer05 headdesks Apr 04 15:31:03 They might be limited to pa or alsa though, but those can output to oss or the other thing. Apr 04 15:31:19 it was just a metaphor Apr 04 15:31:33 bencoh: the concept of midlware aka soundserver completely eludes him Apr 04 15:32:07 "there will prolly be a ofono adapter for GSM in FSO. There will not be any such thin in ofono to use FSO." Apr 04 15:32:10 Maxdamantus: how would you have two concurrent app playing sound at that time (10 years ago) Apr 04 15:32:13 isn't this exactly what I've been saying? Apr 04 15:32:14 . Apr 04 15:32:19 small interface, easy to adapt. Apr 04 15:32:26 (at the *same* time I mean) Apr 04 15:32:41 i think the design concept "just interfaces for various things" is what eludes Maxdamantus idea of software design on a given set of chips and hardware design, other 3rd party software and any other of numerous gotchas DocScrutinizer05 already mentioned Apr 04 15:33:02 that we have to comply with on the n900 Apr 04 15:33:53 I didn't really understand that sentence. Apr 04 15:34:33 me neither, I think a cat ate a few words :) Apr 04 15:35:41 nevermind, i realize i was just trying to repeat what already has been said. and not in a successful way Apr 04 15:35:45 did someone say food? Apr 04 15:36:27 if you usually eat cats, then yeah Apr 04 15:37:03 i try to avoid that, got enough fur to cough up as is Apr 04 15:38:54 when you *are* a cat and cats actually eat words, then too Apr 04 15:40:35 Maxdamantus: it's pretty simple: libisi (is subset of) /dev/tty* (is subset of) ofono (is subset of) fso Apr 04 15:41:41 the more platform independant and cuncurrency-safe you want your app to be, the more to the right a solution you want to pick Apr 04 15:41:46 and ofono is the suitable level for concurrent access. Apr 04 15:42:09 it is ... but for gsm stuff only Apr 04 15:42:10 yes, but only to modem, while FSO has a holistic approach Apr 04 15:42:29 (I'd be fine with that though) Apr 04 15:42:45 with FSO you also can make your APP controll backlight-always-on and GPS and.... Apr 04 15:45:17 and I wonder if ofono has any concept of resource sharing on multi-user environments, while I'm sure FSO at least has thought about how to integrate this aspect. And no, multi-user doesn't mean multipe humans use one phone, it means for example secure namespace separation Apr 04 15:48:31 it means running dialer in a chroot for example Apr 04 15:48:58 or simply under another user Apr 04 15:49:15 so the restriction will be that it can only dial, so only has the dial interface? Apr 04 15:49:48 chroots are kind of ugly for restriction in Linux Apr 04 15:50:07 if you have a procfs mounted, you can just look at /proc/1/root/ Apr 04 15:50:18 (or some other process) Apr 04 15:50:41 sorry, this doesn't sound coherent to me Apr 04 15:51:09 lost in translation, different planets, you know Apr 04 15:52:12 If you're in a chroot and have the same uid as a process outside the chroot, you can open the other process' root directory through a procfs. Apr 04 15:53:39 if the one setting up the chroot was a dummy then yes Apr 04 15:53:51 orcus:~# sha1sum /go Apr 04 15:53:51 a435818c5b375b81e38c3c78c958af645c9eab16 /go Apr 04 15:53:51 orcus:~# chroot /home/debian-armel-root sha1sum /proc/1/root/go Apr 04 15:53:51 a435818c5b375b81e38c3c78c958af645c9eab16 /proc/1/root/go Apr 04 15:54:36 btw on the usual chroot there's only ONE namespace systemwide for process ids Apr 04 15:54:39 You can also just ptrace other processes. Apr 04 15:54:53 if you have the same uid. Apr 04 15:55:17 there CANNOT be a different process in chroot with same process numeric id like another process ourside chroot Apr 04 15:55:30 I'm aware. Apr 04 15:55:52 then you *completely* lost me on what you're telling here Apr 04 15:55:53 The only thing that's different is the "root directory" of a process. Apr 04 15:56:12 A process has a current working directory and a root directory. Apr 04 15:56:22 when you chroot, you just change what the root directory is. Apr 04 15:56:29 DocScrutinizer05: he said same uid, not pid Apr 04 15:56:37 like how when you chdir, you just change what the current working directory is. Apr 04 15:56:44 thanks, I know how chroot (and pivot_root) works Apr 04 15:56:51 ooh, sorry Apr 04 15:57:38 * DocScrutinizer05 heads out to get some breakfast coffee Apr 04 15:57:56 no idea anyway why we're discussing chroots now Apr 04 15:57:56 Plan 9 solved all this namespace stuff properly ages ago. Apr 04 15:58:16 yes, plan9 is fine, alas not very popular Apr 04 15:59:19 this however doesn't mean it was a asmart thing to apply plan9 architectural paradigms to linux apps Apr 04 15:59:48 on plan9 you might even get away without any middleware Apr 04 16:00:05 p9 on n900 ? yay ! Apr 04 16:02:05 They even removed chroot from POSIX because it was silly. Apr 04 16:04:24 POSIX is a subset of linux api, always been Apr 04 16:04:44 not all that's in linux but not in POSIX is silly Apr 04 16:04:45 not Linux. Apr 04 16:04:53 but glibc etc Apr 04 16:05:03 and bash, and gcc Apr 04 16:05:16 but the POSIX library interface is basically glibc. Apr 04 16:06:27 * Maxdamantus was experimenting with some POSIX function before and glibc complained at runtime that it wasn't implemented. Apr 04 16:06:35 execat, iirc Apr 04 16:06:47 er, fexec or fexecv or whatever Apr 04 16:07:17 Hm. What's it called? Apr 04 16:07:25 fexecve -_- Apr 04 16:07:50 "but the POSIX library interface is basically glibc." nope. Apr 04 16:07:53 definitely not. Apr 04 16:08:15 Which bits aren't covered by glibc? Apr 04 16:08:45 unless you're talking about how glibc is just a simple wrapper for some system calls. Apr 04 16:09:09 no I mean, lots of thing in glibc arent posix at all Apr 04 16:09:11 like open/close/read/write, as opposed to pthreads, which the kernel doesn't know anything about. Apr 04 16:09:14 Ah. Apr 04 16:09:37 I just meant the POSIX library interface is all handled by glibc. Apr 04 16:09:48 rather than by Linux or something else. Apr 04 16:13:46 * Maxdamantus sleeps. Apr 04 18:15:39 goddamn nepomuk sematic desktop ate 12GB(!) of RAM and brings my system close to a collapse Apr 04 18:17:06 sure, who needs such crap. but without it I can't even search/filter for "new mail" in kmail/kontact, thanks akonadi==nepomuk it seems Apr 04 18:35:42 Maxdamantus: The Images are about 423KiB Apr 04 21:59:19 [notice] from this very moment, I'm no longer maemo-admin-coordinator/manager Apr 04 21:59:30 DAMN THAT FEELS GOOD! Apr 04 22:01:50 many thanks to the whole techstaff team, been a real pleasure to help you with your tasks. And good luck to whomever will replace my tiny part in it, if anybody Apr 04 22:02:16 heh Apr 04 22:02:21 DocScrutinizer05: GRATULATIOOOOOONNN! :-) Apr 04 22:02:22 and of course good luck to maemo at large Apr 04 22:02:47 What's your current plans= Apr 04 22:02:51 whoever* btw Apr 04 22:02:52 Got beer? Apr 04 22:03:03 (the clause is "whoever will ..") Apr 04 22:03:09 forget about all the abuse I suffered during last few months Apr 04 22:03:45 Maxdamantus: "to whom...", no? Apr 04 22:03:56 DocScrutinizer05: depends. Apr 04 22:04:10 well, pardon my french then Apr 04 22:04:13 * ShadowJK currently works maintenance at $work and can sure relate to not being liked :) Apr 04 22:04:19 "to whom the bell tolls" Apr 04 22:04:23 "to who tolls the bell" Apr 04 22:04:46 aaah, thanks a lot Apr 04 22:04:53 think I got it Apr 04 22:05:29 np **** ENDING LOGGING AT Sat Apr 05 02:59:58 2014