| 00:26.44 | *** join/#openmoko apt (ibot@rikers.org) |
| 00:26.44 | *** topic/#openmoko is Openmoko Mobile Phone Hardware users | Developers channel #openmoko-cdevel | German folks channel #openmoko-de | New Users read http://wiki.openmoko.org + http://www.catb.org/~esr/faqs/smart-questions.html | chanlogs: ~logs | distro-specific channels: #qtmoko, #android-on-freerunner, #openmoko-debian |
| 00:26.44 | *** mode/#openmoko [+v apt] by ChanServ |
| 00:30.49 | *** join/#openmoko apt (ibot@rikers.org) |
| 00:30.49 | *** topic/#openmoko is Openmoko Mobile Phone Hardware users | Developers channel #openmoko-cdevel | German folks channel #openmoko-de | New Users read http://wiki.openmoko.org + http://www.catb.org/~esr/faqs/smart-questions.html | chanlogs: ~logs | distro-specific channels: #qtmoko, #android-on-freerunner, #openmoko-debian |
| 00:30.49 | *** mode/#openmoko [+v apt] by ChanServ |
| 00:34.00 | *** join/#openmoko apt (ibot@rikers.org) |
| 00:34.00 | *** topic/#openmoko is Openmoko Mobile Phone Hardware users | Developers channel #openmoko-cdevel | German folks channel #openmoko-de | New Users read http://wiki.openmoko.org + http://www.catb.org/~esr/faqs/smart-questions.html | chanlogs: ~logs | distro-specific channels: #qtmoko, #android-on-freerunner, #openmoko-debian |
| 00:34.00 | *** mode/#openmoko [+v apt] by ChanServ |
| 02:20.18 | *** join/#openmoko genpaku (~genpaku@107.191.100.185) |
| 04:51.09 | *** join/#openmoko DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 05:35.38 | *** join/#openmoko apt (ibot@rikers.org) |
| 05:35.38 | *** topic/#openmoko is Openmoko Mobile Phone Hardware users | Developers channel #openmoko-cdevel | German folks channel #openmoko-de | New Users read http://wiki.openmoko.org + http://www.catb.org/~esr/faqs/smart-questions.html | chanlogs: ~logs | distro-specific channels: #qtmoko, #android-on-freerunner, #openmoko-debian |
| 05:35.38 | *** mode/#openmoko [+v apt] by ChanServ |
| 05:43.22 | *** join/#openmoko balrog-k1n (~balrog@89-67-121-18.dynamic.chello.pl) |
| 06:09.25 | *** join/#openmoko thereyougo (partyinpar@unaffiliated/thereyougo) |
| 06:09.54 | thereyougo | anyone here ? |
| 06:10.39 | thereyougo | so openmoko was created even before android or iphone ? in essence it was linux on phone ? why it didn't ganed such popularity as android or iphone ? |
| 06:11.05 | thereyougo | ~logs |
| 06:11.05 | apt | All conversations are logged to http://apt.rikers.org/%23openmoko/ Lines starting with spaces are not logged. Logs are updated daily --- livelogs are on http://logs.nslu2-linux.org/livelogs/openmoko.txt |
| 06:59.32 | *** join/#openmoko Q-Master (~q-master@2.93.107.124) |
| 07:02.10 | PaulFertser | thereyougo: hi |
| 07:02.43 | PaulFertser | thereyougo: well, I'd say that it had plenty of shortcomings in comparison, that's why |
| 07:04.01 | PaulFertser | thereyougo: it wasn't that much appealing even to geek/hacker audience, so the general community was impossible to get interested in this project |
| 07:04.58 | PaulFertser | thereyougo: Nokia's n900 was much less free and yet it had way more success |
| 08:14.17 | *** join/#openmoko amarsh04 (~amarsh04@ppp118-210-107-205.bras2.adl4.internode.on.net) |
| 09:31.26 | thereyougo | and yet, the irony is, now, this is what many people do with iphone and android they rooting it they install native unix software on it, they actually trying to make it into a what openmoko tryed to be initially, right ? |
| 09:31.57 | thereyougo | its like, they didn't wanted "freedom" initially now they have to fight for it ? |
| 09:32.26 | PaulFertser | thereyougo: that's not the same level of freedom. You can install unix tools in chroot on any android even without root permissions. |
| 09:34.03 | thereyougo | or maybe I biased by this talk: https://www.youtube.com/watch?v=SGmtP5Lg_t0 |
| 09:34.05 | thereyougo | "Embedded Linux Conference 2013 - Toybox - Writing a New Command Line From Scratch" |
| 09:34.10 | thereyougo | just watch first 10 minutes where author tells about "why" toybox |
| 09:35.13 | thereyougo | in short, he says android is not vanilla linux and all base tools in android very stripped down to not give too much freedom for exploitation and make it more secure |
| 10:10.42 | *** join/#openmoko geaaru (~geaaru@host139-6-dynamic.54-82-r.retail.telecomitalia.it) |
| 10:40.59 | DocScrutinizer05 | chroot without root permissions? |
| 10:49.49 | DocScrutinizer05 | the (android security) approach is flawed in my book, or the explanation is. A unix system with a good root password been relatively safe from threats for like 50 years now |
| 10:50.32 | DocScrutinizer05 | you don't need to strip down tools, you need to secure them |
| 10:50.44 | DocScrutinizer05 | that's what permissions are meant for |
| 10:52.27 | DocScrutinizer05 | in real life, with totally 'illiterate' users, the situation is slightly more complex but still basically boils down to exactly that. What android does isn't reduce attack surface, it is "create a secure environment for third party apps", aka DRM |
| 10:54.24 | DocScrutinizer05 | it's just *they* don't want _you_ to do whatever you like on your device. And that's exactly why users search for ways to get past this limitations since they actually want to do stuff they 'are not supposed to be able to do' |
| 10:55.05 | DocScrutinizer05 | ~trust |
| 10:55.05 | apt | somebody said trust was safe, or http://www.youtube.com/watch?v=0cbS_lDJuJg |
| 11:01.06 | DocScrutinizer05 | PaulFertser: the N900 isn't THAT MUCH less free than openmoko |
| 11:02.01 | DocScrutinizer05 | actually the only thing you can't replace by your own stuff is the MLO bootloader, isnce it's a HS device |
| 11:02.51 | DocScrutinizer05 | the rest is, well they ship some closed source apps with the device, but you're free to not use them and install and use your own alternative instead |
| 11:04.36 | DocScrutinizer05 | PaulFertser: you might be interested in recent development of completely FOSS maemo based on devuan |
| 11:10.45 | DocScrutinizer05 | the N9 with meego HARMattan aka maemo6 was a TCPA crap device, thanks to aegis activating and putting to purpose the MLO based TrustZone/M-Shield crap. N900 had same hardware but it never got activated |
| 11:13.34 | DocScrutinizer05 | ~aegis |
| 11:13.34 | apt | http://www.developer.nokia.com/Community/Wiki/Harmattan:Developer_Library/Developing_for_Harmattan/Harmattan_security/Security_guide , or "The purpose of this framework is: ... to make sure that the platform meets the requirements set by third party software that requires a safe execution environment.", or http://en.wikipedia.org/wiki/Trusted_Computing#Criticism, or http://en.qi-hardware.com/w/images/1/10/ME_382_LockedUpTechnology2.gif |
| 11:14.15 | thereyougo | ~harambe |
| 11:15.03 | thereyougo | ~harmattan |
| 11:15.04 | apt | rumour has it, harmattan is teh suck |
| 11:18.12 | PaulFertser | DocScrutinizer05: well, n900 gained traction without free drivers for most of the important hardware. My point is that the level of freedom OM could offer wasn't an important part for the larger audience, even for programmers/enthusiasts. |
| 11:18.36 | DocScrutinizer05 | the drivers all been always free |
| 11:18.49 | PaulFertser | All modem stuff was closed |
| 11:19.05 | PaulFertser | And the shitty bmc or whatever it was called. |
| 11:19.05 | DocScrutinizer05 | otherwise Nokia had violated GPL |
| 11:19.34 | PaulFertser | Free kernel drivers weren't that much important, yes, they just outsourced plenty of real work to closed-source userspace. |
| 11:19.49 | DocScrutinizer05 | BME is a userland daemon to tickle the watchdog of the charger chip |
| 11:20.53 | DocScrutinizer05 | I replaced it by a shellscript 5liner pretty soon after N900 got available |
| 11:21.12 | PaulFertser | I do not remember the details but even at the moment we were working on hostmode-easy-now (so, 2 years or so after release) I wasn't able to use it as my phone because of the proprietary userspace components. |
| 11:21.36 | DocScrutinizer05 | Nokia didn't open this one up since they were afraid of getting sued for exploding batteries |
| 11:22.20 | PaulFertser | If it was only a matter of running your shell script I wouldn't mind. |
| 11:23.32 | DocScrutinizer05 | there's a lot of other stuff not FOSS, that's true. But installing and running a plain linux like debian wasn't a big thing, except for the phone functionality |
| 11:25.02 | DocScrutinizer05 | they documented the ISI protocol in some not exactly public but available specs, but they didn't open up the source of their drivers for that abomination |
| 11:26.17 | DocScrutinizer05 | yet freesmartphone.org and ofono were able to implement the ISI protocol |
| 11:27.08 | DocScrutinizer05 | pathetic or non-existing Board Support Package != non-open |
| 11:29.46 | DocScrutinizer05 | btw meanwhile as far as I know all the mandatory stuff is mainlined |
| 11:30.47 | DocScrutinizer05 | for BME Pali Rohar made a kernel driver according to my specs |
| 11:32.07 | DocScrutinizer05 | the problem back when, at 'your' time, was that HAL didn't talk to my script, so the battery gauge and thus the system shutdown at low battery didn't work |
| 11:32.45 | DocScrutinizer05 | Pali fixed that too |
| 11:37.05 | DocScrutinizer05 | >>My point is that the level of freedom OM could offer wasn't an important part for the larger audience<< so far I agree |
| 11:39.16 | DocScrutinizer05 | for devels it always been an issue for N900 that Nokia had that closed stuff in maemo. Just because the devels seen the potential and general maturity of maemo and were fully aware of the pending problems from the closed parts |
| 11:40.22 | DocScrutinizer05 | #maemo 155 users, #harmattan 49 users |
| 11:40.25 | DocScrutinizer05 | ;-) |
| 11:44.37 | PaulFertser | Is there currently a free software stack that provides stable and reliable voice, SMS and GPRS functionality? |
| 11:46.45 | DocScrutinizer05 | it's maybe very similar to systemd situation. Imagine systemd wasn't FOSS (which arguably it actually isn't really). There exist alternatives for all of the functionality it seized, but it's basically another system when you rip out systemd and all the stuff that depends on it. See https://devuan.org/os/packages/list/forked-from-debian - same with modem in maemo, when you replace it by e.g ofono, you need a new dialer which also is |
| 11:46.46 | DocScrutinizer05 | closed. No big thing to write a new dialer. But then you need one that interfaces with addressbook aka contacts if you want a decent one. And so on |
| 11:47.33 | DocScrutinizer05 | I think SHR did, at times |
| 11:48.03 | DocScrutinizer05 | (provide voice etc) |
| 11:48.11 | PaulFertser | SHR can't talk to ofono, and FSO never fully supported n900's modem iirc. |
| 11:48.23 | DocScrutinizer05 | I think it does |
| 11:49.19 | DocScrutinizer05 | actually Mickey 'stole' the code from ofono iirc |
| 11:49.42 | PaulFertser | There was also PA involved |
| 11:50.55 | DocScrutinizer05 | yes, cmtspeech |
| 11:52.39 | DocScrutinizer05 | https://www.ixquick.com/do/search?q=cmtspeech |
| 11:54.26 | DocScrutinizer05 | the rest are some audio enhancement libs Nokia developed. They don't do key magic, just improve audio quality which is a highly relevant know how asset for Nokia, so they didn't open those up |
| 11:55.05 | DocScrutinizer05 | you can get do without them anyway |
| 11:55.31 | DocScrutinizer05 | meego demonstrated that on N900 iirc |
| 11:55.51 | PaulFertser | Audio quality with calypso remained an issue unfortunately. |
| 11:55.58 | DocScrutinizer05 | indeed |
| 11:56.28 | PaulFertser | So TI, being super-pro with DSP apparently couldn't implement enough "magic" in their firmware. |
| 11:56.30 | DocScrutinizer05 | it wasn't calypso but our pathetic EMI design |
| 11:57.03 | PaulFertser | Hm, how so? I thought the main issue was echo that resulted from acoustic coupling. |
| 11:57.21 | PaulFertser | (main issue after the "capacitor fix" of course) |
| 11:57.22 | DocScrutinizer05 | together with por knowledge how to set the right parameters for the calypso DSP |
| 11:57.37 | DocScrutinizer05 | poor* |
| 11:58.10 | DocScrutinizer05 | yes, that was pathetic ME and acoustic design |
| 11:58.24 | PaulFertser | I thought Dieter knew enough about all the settings. |
| 11:58.33 | DocScrutinizer05 | not of the DSP |
| 11:59.10 | DocScrutinizer05 | he was only ever involved in the radio stack and AT interpreter |
| 11:59.10 | PaulFertser | btw, even not securing those two screws that held the case together was resulting in reducing echo considerably. |
| 11:59.25 | DocScrutinizer05 | HAHA nice |
| 11:59.27 | PaulFertser | But then there was tnt's work. |
| 11:59.51 | PaulFertser | Who fully dumped the DSP firmware and disassembled and modded it iirc. |
| 12:00.11 | DocScrutinizer05 | boooh never heard of that. awesome |
| 12:00.52 | DocScrutinizer05 | I actually don't even know of an assembler for that DSP crap |
| 12:01.00 | PaulFertser | http://people.osmocom.org/tnt/talks/phdays2012-abusing-calypso-phones.pdf |
| 12:03.06 | DocScrutinizer05 | umm, is that the radio DSP? or the audio DSP? |
| 12:04.51 | PaulFertser | Does it have several? |
| 12:07.35 | DocScrutinizer05 | I'd think so |
| 12:08.12 | DocScrutinizer05 | or they use same DSP for both radio signal processing and audio signal processing |
| 12:08.57 | DocScrutinizer05 | anyway the DSP as shown in there in the block diagrams is in a slightly incorrect position for audio processing |
| 12:11.43 | DocScrutinizer05 | well. maybe not, the ARM samples audio via a (not shown) ADC from analog audio in, then it m,ay have it processed by DSP, then process it by ARM itself for whatever needed (mute, whatnot else, building packets for GSM 20ms slots) then send the data packets to DSP again to convert them to the data needed to control the radio frontend |
| 12:35.33 | DocScrutinizer05 | or they do it in ARM even |
| 12:35.40 | DocScrutinizer05 | like on N900 ;-D |
| 12:36.36 | DocScrutinizer05 | looking at it from this PoV, it seems to me N900 is even slightly more open than GTA02 ;-) |
| 12:38.28 | DocScrutinizer05 | on N900 maemo the DSP audio processing for echo cancelation etc is done by PA plugins, and the 20ms packeting and serialization is done by the cmtspeech stuff |
| 12:39.26 | DocScrutinizer05 | the latter is a big PITA btw, since you need to obey modem as master for the audio sampling rate and packet delivery |
| 12:40.14 | DocScrutinizer05 | and that's been the big problem with many implementations for modem audio |
| 12:41.29 | DocScrutinizer05 | I don't know why, after all it's not any different to what you need to do for e.g. SIP RTP audio |
| 12:47.51 | DocScrutinizer05 | when your local audiocard ADC clock (or, for SIP RTP, the inbound packet rate) develops a skew from a slightly off pace on either end, you need to drop or duplicate a packet to reduce the skew to allowable limit. This linit is _not_ 20ms like suggested in that whitepaper by a Nokia employee, you could as well allow a max of 50ms skew which enables using 3 20ms buffer segments |
| 12:48.14 | DocScrutinizer05 | while that Nokia guy uses 4 5ms segments |
| 12:49.41 | DocScrutinizer05 | actually you could even drop or duplicate single frames aka samples to shift the write or read position gradually |
| 13:10.10 | *** join/#openmoko Wuzzy (~Wuzzy@p5B0DF7AA.dip0.t-ipconnect.de) |
| 15:43.52 | *** join/#openmoko balrog-k1n (~balrog@89-67-121-18.dynamic.chello.pl) |
| 19:13.36 | *** join/#openmoko PBeck (~PBeck@unixboard/users/pbeck) |
| 19:30.01 | *** join/#openmoko Wuzzy (~Wuzzy@p5B0DF7AA.dip0.t-ipconnect.de) |
