ubuntu-phone team mailing list archive

[Richard Somlói <level@xxxxxxxxxxxxxxxx>]

Could we somewhere find this result? I'm very excited because of this. :)

2015-10-09 13:20 GMT+02:00 Benjamin Zeller <benjamin.zeller@xxxxxxxxxxxxx>:

> Am 09.10.2015 um 12:56 schrieb Thomas Voß:
>
>> On Fri, Oct 9, 2015 at 12:55 PM, Michael Zanetti
>> <michael.zanetti@xxxxxxxxxxxxx> wrote:
>>
>>>
>>> On 09.10.2015 12:48, Thomas Voß wrote:
>>>
>>>> On Fri, Oct 9, 2015 at 12:43 PM, Michael Zanetti
>>>> <michael.zanetti@xxxxxxxxxxxxx> wrote:
>>>>
>>>>>
>>>>> On 09.10.2015 11:49, Pete Woods wrote:
>>>>>
>>>>>>
>>>>>> On Thu, Oct 8, 2015 at 12:41 PM, Thomas Voß <
>>>>>> thomas.voss@xxxxxxxxxxxxx
>>>>>> <mailto:thomas.voss@xxxxxxxxxxxxx>> wrote:
>>>>>>
>>>>>>      On Thu, Oct 8, 2015 at 1:36 PM, Michi Henning
>>>>>>      <michi.henning@xxxxxxxxxxxxx <mailto:michi.henning@xxxxxxxxxxxxx
>>>>>> >>
>>>>>>      wrote:
>>>>>>      >> you can indeed build apps in C++ if you want, but C++ is more
>>>>>> complex to
>>>>>>      >> understand and write (if you ever did a dynamic web page in
>>>>>> your life
>>>>>>      >> you likely know the basics of js). C++ needs a (cross) compile
>>>>>>      >> environment set up while js means you can just dump a txt
>>>>>> (well, .qml)
>>>>>>      >> file in place and it just works. Doing C++ is just a lot more
>>>>>> work and
>>>>>>      >> while you can use C++ I think people find it easier to simply
>>>>>> use js (I
>>>>>>      >> surely do, i can write a ready made QML app including rolling
>>>>>> the click
>>>>>>      >> and uploading it to the store with a plain text editor within
>>>>>> 20min, I
>>>>>>      >> (personally) cant do that in C++)) ...
>>>>>>      >
>>>>>>      > Writing a dynamic web page in C++ is a bit like writing a
>>>>>> neural network in COBOL. Don't.
>>>>>>      >
>>>>>>      > Would I write a device driver in JS? Probably not.
>>>>>>      >
>>>>>>      > Would I try to tighten a Phillips head screw with a nail file?
>>>>>> Probably not either.
>>>>>>      >
>>>>>>      > I think you get the drift… :-)
>>>>>>      >
>>>>>>
>>>>>>      +1 :)
>>>>>>
>>>>>>      Please note that qml and c++ components are happily mixed
>>>>>> together
>>>>>>      with QML/Qt. If there is a serious performance issue with using
>>>>>> pure
>>>>>>      QML,
>>>>>>      falling back to C++ is always possible.
>>>>>>
>>>>>>
>>>>>> Remember everyone, that Android apps launch pretty quickly, and they
>>>>>> are
>>>>>> Java based
>>>>>> (and were only natively compiled with the release of Lollipop's ART).
>>>>>>
>>>>>> This is achieved through the use of a "Zygote" process and some clever
>>>>>> copy-on-write
>>>>>> page management (I *think* using special kernel patches). There is
>>>>>> always a
>>>>>> pre-warmed instance of the JVM ready, and it is forked each time a new
>>>>>> app / service
>>>>>> wants to launch. The page copy-on-write behaviour allows a new JVM
>>>>>> instance to be
>>>>>> spawned with almost no effort to the phone (you only copy the memory
>>>>>> if
>>>>>> you alter the
>>>>>> Java runtime libs in some way, which is uncommon) and comes with large
>>>>>> memory savings.
>>>>>>
>>>>>> The summary of what I'm saying is the old adage "there are no slow
>>>>>> programming languages,
>>>>>> only slow programs". I think a lot of our app launch speed troubles
>>>>>> could be alleviated by
>>>>>> employing the same techniques that Google does. The answer to
>>>>>> performance issues
>>>>>> is rarely to "switch programming language", assuming you're using a
>>>>>> language that at
>>>>>> least has a JIT compiler.
>>>>>>
>>>>>> FWIW, Benjamin is experimenting with MeeGo's applauncherd/booster,
>>>>> which
>>>>> in principle does pretty much what you're describing. First tests do
>>>>> suggest that it does improve the situation quite a bit. Details still
>>>>> to
>>>>> be ironed out tho.
>>>>>
>>>>> where "details" are actual security issues that we have to solve prior
>>>> to even start benchmarking :)
>>>>
>>> The main concerns of the security team have already been addressed
>>> afaik. I might not have the full details tho.
>>>
>> The main concern was that using mapplauncherd would weaken ASLR, however
> we managed to work around that issue and our profiling was showing pretty
> good
> results.
>
> Now we are waiting for the security team to review what we have. Only
> after we
> got a OK from them we can release something :).
>
> Cheers
>
> Benjamin
>
> Even better then, I will see if I can get Jamie to respond to this thread.
>>
>> Cheers,
>>
>>    Thomas
>>
>> The difficulty is _not_  in keeping a set of pre-warmed processes
>>>> around to make app startup a rolling start.
>>>> But implementing a solution that is both secure *and* provides
>>>> significant improvements of app-startup time.
>>>>
>>>> Cheers,
>>>>
>>>>    Thomas
>>>>
>>>> Br,
>>>>> Michael
>>>>>
>>>>>
>>>>> --
>>>>> Mailing list: https://launchpad.net/~ubuntu-phone
>>>>> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~ubuntu-phone
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>