Thank you a lot, mingw!

Why do not google officially move to 4.6.x Linaro toolchains? I think
the reason is following:
(1) Mer don't have a lot of legacy baggage it's forced to carry, So
Mer can move to advanced toolchains easily;
(2) Android is such a huge monster that it is hard for android to move
to advanced toolchains.
Is the above reason right?

Thanks!

BR
zhanghui

On 1/25/12, mingw android <[email protected]> wrote:
> On Wed, Jan 25, 2012 at 8:48 AM, Hui Zhang <[email protected]> wrote:
>> On 1/24/12, Carsten Munk <[email protected]> wrote:
>>> 23. jan. 2012 13.15 skrev Hui Zhang <[email protected]>:
>>>> Hi all,
>>>>     I am considering one important question: What is Mer's advantage
>>>> over
>>>> Android?  In technical point of view, in marketing point of view, etc...
>>>> Any
>>>> are appreciated:)
>>>>
>>>>     In 2012 Q1,  an important task for me is to convince TV vendors
>>>> (even
>>>> chip vendors such as MSTAR and MTK) that Mer can replace Android well.
>>>>     If I can say something about Mer's advantage, it will do great help.
>>>
>>> A very big question :) On technical point of view, we have advantages
>>> such
>>> as:
>>>
>>> * Our source code is always available and accessible, so you and your
>>> company can see what direction the Mer stack is going in and influence
>>> it. In Android, not even partners in Open Handset Alliance (except
>>> maybe the people doing a lead device) gets to see the source code
>>> before release. In practice, this means that any contributions you may
>>> do to Android will likely never get merged as the source code that
>>> exists externally may have moved on significantly internally.
>>>
>>    Agree. As far as openness is concerned, Mer is better than Android.
>>
>>> * Ability to use most open source software and libraries out there
>>> with ease, as we are implementing a full set of POSIX APIs as we use
>>> glibc. Android's bionic only implements a subset and doesn't implement
>>> things like C++ exceptions.
>>    Agree. As far as compatibility to linux community is concerned,
>> Mer is better than Android.
>>>
>>> * Mer is designed to be a core for many different kind of mobile
>>> devices, while Android is built with focus of being for handsets -
>>> just remember the difficulties with Honeycomb and enabling tablet
>>> usage.
>>    I don't quite catch this. What difficulites with Honeycomb for
>> tablet usage?
>>   And as for TV, googleTV was announced May, 2010; And In 2011,
>> Serveral companies such as LG took android TV into account.
>>   In this point of view, what does Mer provides?
>>>
>>> * Mer is optimized for ARM using the Linaro GCC 4.6.2 toolchains and
>>> deliverables, giving bleeding edge performance optimizations, while
>>> Android is currently is on 4.4.
>>   I think Android can also use Linaro GCC4.6.2(or more advanced
>> toolchains than 4.4). Do you think that there exist some difficulites
>> for android to use Linaro GCC4.6.2 or alike?
>
> I can answer this as I've had a hand in the 4.6.x Linaro toolchains
> used by both Mer and Android (I provide my own version of the NDK
> which I think was the first NDK to move over to using Linaro's
> releases). Yes, both can use Linaro 4.6.x (so long as you follow the
> ABI any code generator can be used - of course with Android, you're
> not using Google officially sanctioned toolchain which is still at
> 4.4.3). The critical difference between Mer and Android in this regard
> is that on Mer, the entire system is built with 4.6.3 whereas on
> Android it's only apps built with the NDK that can take advantage of
> the improvements (should the app developer know about the alternative
> NDKs or care about performance or neon). The manufacturers will be
> using GCC 4.4.3 for the kernel and all the standard Android bits. On a
> tangential point, any Android devs using a 4.4.3 toolchain should also
> avoid using any neon intrinsics as 4.4.3 neon is totally bust.
>
>>>
>>> * Mer is flexible, you can pick and choose what components you'd like
>>> to include in an image - and is meant to be ultraportable to many
>>> different kind of devices. The idea is that you can with ease switch
>>> hardware adaptation, or UX and spread across many kind of different
>>> devices.
>>    Maybe android also can do this...? I don't quite understand.
>>>
>>> * Mer supports multiple application stories, C, C++, HTML5, QML,
>>> JavaScript, etc.
>>    Yes, If Mer can do well in supporting HTML5 apps, that's very good:)
>>>
>>> * Mer can take full advantage of graphics acceleration through GPU,
>>> especially with Qt5's scenegraph work. As well as multiple graphics
>>> backends, X11, wayland, DirectFB, etc.
>>   As for multiple graphics backends, it is Mer's compability advantage;
>>   But how to understand "Mer can take full advantage of graphics
>> acceleration through GPU"? I think android's graphics acceleration
>> have already done a good job:)
>>>
>>> * Mer tries to make life easy for vendors wanting to make Mer products
>>> - as well as having a organisation that allows people to work together
>>> without the project giving preferential treatment to certain partners,
>>> or abuse influence to gain preference in the OS to a certain company's
>>> products, both chipset, internet services or phones. We also support
>>> easily ramping up bigger and multiple teams to do parts of Mer-based
>>> products.
>>  Yes, agree this:)
>>>
>>> * Mer is a cost-saver, it enables you to take full advantage of a
>>> mobile Linux distribution without having to maintain a big team to
>>> have it maintained for you - just share the work with others.
>>  Yes, it's right:)
>>>
>>> Some might say that it not being Android is an technical advantage -
>>> but I think it's also useful to look at the disadvantages.
>>>
>>> Things that are good about Android but at same time bad for the
>>> ecosystem in general:
>>>
>>> * Low footprint due to bionic libc usage, but it makes it incompatible
>>> with much of current open source software
>>
>>> * Good hardware integration with many boards, but it makes life
>>> difficult for anyone wanting to do anything besides Android based
>>> products, as it's tied to the special libc
>>
>>   Yes. Now a lot of people agree, they need something other than
>> Android, they need a good replacement for Android.
>>>
>>> .. hope that helps a bit. The good thing about Mer is that it's a
>>> quite small stack for running Linux/Qt/HTML5 on a lot of different
>>> devices. And that it allows a lot of flexibility in how you make your
>>> product(s) including how to easily save effort in development as you
>>> can use same methods and cores even if you're making a small STB or a
>>> full smartphone.
>>>
>>
>>> BR
>>> Carsten Munk
>>>
>>>
>>>
>>
>>
>
>
>


Reply via email to