[Vlad Dl]

I believe there was a vote somewhere already who wants BB to continue with OS10. One time I was getting "suppose" messages from BBM where my phone would make sound for BBM but nothing came in and this was going on for a while. I guess they were checking who is still active user. My partner was experiencing the same. I guess they have their numbers and know that OS10 was dying. Shouting down BBM server was massive loss for many who were using it even on other platforms. New technology now supports what BB was using back then and hiccup with their email servers was anther faux pax.
If they decide to bring back OS10 what advantages would they be looking to have over current mobile phone makers? Except privacy?
I would be looking at great features like Titan Unihertz has. If that piece of nothing wouldn't have that GOOGLE all over it I would be buying it yesterday or at the release day.

Is privacy and security on Android achieved with all BBAndroid phones? I'm not convinced.

[bb10adopter111]

Why on Earth would they ditch this for Android and start all over again with that? They should have expected new system to pick up at last not in a year or so. Makes me wonder how dumb Mr Chen has to be to jump from platform to platform. How much money they have spent securing Android to their liking? Is it really secure? It shows freaking Google search on home screen.

I'm not sure what you're asking me. You grabbed a quote of mine out of context and are asking me something I know nothing about. Presumably, BlackBerry saw a business opportunity and pursued it, based on information available at the time. Beyond that, I could not speculate.

Z10 = BB10 + VKB > iOS + Android

[joeldf]

Why on Earth would they ditch this for Android and start all over again with that? They should have expected new system to pick up at last not in a year or so. Makes me wonder how dumb Mr Chen has to be to jump from platform to platform. How much money they have spent securing Android to their liking? Is it really secure? It shows freaking Google search on home screen.

Because BB was losing so much money on BB10 that the Board of Directors hired Chen to do exactly what he did. Securing Android is actually much easier (cheaper), relatively speaking, since it involves using existing methods built into the SOCs that most OEMs simply don't use.

[Dunt Dunt Dunt]

Why on Earth would they ditch this for Android and start all over again with that? They should have expected new system to pick up at last not in a year or so. Makes me wonder how dumb Mr Chen has to be to jump from platform to platform. How much money they have spent securing Android to their liking? Is it really secure? It shows freaking Google search on home screen.

Chen not dumb at all.... BB10 was doomed and he kill it off as quickly as he could, and won't be bring it back

I expect BB Android was a result of the three big App Suites they looked at doing anyway. At some point a senior developer said... why not just release and Android phone too.

[app_Developer]

Chen not dumb at all.... BB10 was doomed and he kill it off as quickly as he could, and won't be bring it back

I expect BB Android was a result of the three big App Suites they looked at doing anyway. At some point a senior developer said... why not just release and Android phone too.

Yes plus they had hundreds of millions of dollars in outstanding purchase commitments that Chen either had to settle or burn down. The only option if you are contractually committed to buying that much phone stuff is to put together an android phone and hope you can sell it.

Well the other option is a negotiated settlement but that’s a bitter pill to swallow. I hope they at least explored that.

[DonHB]

Yes plus they had hundreds of millions of dollars in outstanding purchase commitments that Chen either had to settle or burn down. The only option if you are contractually committed to buying that much phone stuff is to put together an android phone and hope you can sell it.

Well the other option is a negotiated settlement but that’s a bitter pill to swallow. I hope they at least explored that.

Could also have sold the commitment to buy at a loss? The loss may have been equivalent to hardware R&D. This may have allowed it to break even. It would have allowed BB exit hardware earlier and use the money to extend maintenance mode longer? It may have meant no Priv or Passport. Or the commitments were for older tech and no takers.

[DonHB]

Why on Earth would they ditch this for Android and start all over again with that? They should have expected new system to pick up at last not in a year or so. Makes me wonder how dumb Mr Chen has to be to jump from platform to platform. How much money they have spent securing Android to their liking? Is it really secure? It shows freaking Google search on home screen.

It is possible that with 64-bit QNX three years away was a also factor for why BB10 was EoL'd. The competition already moved to 64-bits. Also, I suspect there were no customers asking for cellular communications to be added to the car platform or if BB had customers delivery was also years away. This prohibited sharing R&D costs across product lines (many here say savings would be minimal). It would be interesting to know how many remain at BB that worked on BB10. More interesting, if they are now part of QNX.

[DonHB]

Without having a QNX/BB10 developer symposium at BlackBerry, you aren't going to get the granular details you are requesting.

None of this matters of course, since the things we DO know make this economically undoable anyway.

You're simply trying to get a good deal on deck chairs for the Titanic.

This was actually part of general questions about development on SoCs not specifically about BB10.

[DonHB]

...Your idea is based on an extremely shallow understanding of the technologies involved, the business strategy of BB, the tech industry, the mobile industry and most of all ARM processors and SoCs that some of us have actually worked with in our careers. So if you cannot or will not listen to any feedback on your idea and you still think you can make this work, then BB should be your next call.

Aside from the issue of battery performance a lot of what you have asserted is from the perspective of competitiveness for the hardware vender and for the non-niche platform vender (i.e Apple and Android licensees).

For this niche market what would be good enough? A hand warmer isn't good enough. If using hardware that is six years newer with less optimized software is a performance upgrade and is at least as good as the Passport in terms of battery performance it could be good enough. What is good enough is also about addressing the financial aspects that everyone has been raising about this proposition. This makes the choice of where to invest in the platform a question of customer requirements as is the possibility of a longer product cycle as compared to iPhone and Android. This approach would also likely reduce time to market.

The survey was intended to be a starting point in determining what is good enough. It could also be used to prioritize what would be next in investment should there be sufficient buy-in.

[DonHB]

Where are you planning to pick up a modern, performant, energy efficient, native mobile web browser?

Would this browser work?

Another case of applicable assets?

[app_Developer]

Could also have sold the commitment to buy at a loss? The loss may have been equivalent to hardware R&D. This may have allowed it to break even. It would have allowed BB exit hardware earlier and use the money to extend maintenance mode longer? It may have meant no Priv or Passport. Or the commitments were for older tech and no takers.

Why would someone buy a purchase obligation from the obligor?

If I owe you money, you can sell that debt for a discount. But I can’t sell that debt!

Similarly, Nobody is going to pay me for the opportunity to be obliged to buy hundreds of millions of dollars worth of stuff.

[app_Developer]

Would this browser work?

Another case of applicable assets?

Yes, that looks like a good start! We don’t buy that part of the QNX stack so I didn’t know they had that. We do all that ourselves where I work.

So now they need to optimize that for a much smaller device with much less power. That’s the difference between Safari and Mobile Safari, for example.

So still work to do, but it’s a good start.

[app_Developer]

Aside from the issue of battery performance a lot of what you have asserted is from the perspective of competitiveness for the hardware vender and for the non-niche platform vender (i.e Apple and Android licensees).

For this niche market what would be good enough? A hand warmer isn't good enough. If using hardware that is six years newer with less optimized software is a performance upgrade and is at least as good as the Passport in terms of battery performance it could be good enough. What is good enough is also about addressing the financial aspects that everyone has been raising about this proposition. This makes the choice of where to invest in the platform a question of customer requirements as is the possibility of a longer product cycle as compared to iPhone and Android. This approach would also likely reduce time to market.

The survey was intended to be a starting point in determining what is good enough. It could also be used to prioritize what would be next in investment should there be sufficient buy-in

Like you said, hand-warmer isn’t good enough. And eventually the phone will shutdown and not start again until it has cooled enough. Maybe your target market of super fans will tolerate it.

You should make the survey or tell us what you would like in it.

[DonHB]

Yes, that looks like a good start! We don’t buy that part of the QNX stack so I didn’t know they had that. We do all that ourselves where I work.

So now they need to optimize that for a much smaller device with much less power. That’s the difference between Safari and Mobile Safari, for example.

So still work to do, but it’s a good start.

I guess the correct comment is pay a company to take the obligation thereby reducing the cost to the recipient and minimizing the cost to BlackBerry.

[DonHB]

https://community.arm.com/developer/...t-applications

Like you said, hand-warmer isn’t good enough. And eventually the phone will shutdown and not start again until it has cooled enough. Maybe your target market of super fans will tolerate it.

It may make sense to keep the upgraded Android Player at 32-bits. Also, QNX 7 does not support extended memory (in 32-bit mode), but custom memory management modules are possible. The issue, at the beginning, is supporting all the handset's memory not executing 64-bit apps.

I want to add that I found this post from ARM Community from years ago. It claims that ARMv8 allows the kernel to run in 64-bit while efficiently allowing apps to run in 32-bits. It appears to claim to have demoed 32-bit Android (VM?) running on 64-bit Linux. What am I missing?

You should make the survey or tell us what you would like in it.

It is tough to answer. Primarily because if the wording is wrong or misleading it will misrepresent the idea. Making it clear this is only software and that there will be no handsets with BlackBerry branding or any likelihood of a PKB may be disappointing. Further, even less likely than BB accepting this proposition is BB choosing a handset without hardware root of trust. Explaining this is necessary to emphasize that the choice of hardware is limited. There is also the question of upgrading the Android Player and to what level API. Even with the issues with the current Android Player, can Dalvik be made to support API 28? I would think the switch to ART could be just as difficult, but would make the choice of API level less problematic.

Maybe the survey wording can be made simple by limiting this to software features leaving the questions of handset choice and API level for later.

[app_Developer]

https://community.arm.com/developer/...t-applicationsIt may make sense to keep the upgraded Android Player at 32-bits. Also, QNX 7 does not support extended memory (in 32-bit mode), but custom memory management modules are possible. The issue, at the beginning, is supporting all the handset's memory not executing 64-bit apps.

I want to add that I found this post from ARM Community from years ago. It claims that ARMv8 allows the kernel to run in 64-bit while efficiently allowing apps to run in 32-bits. It appears to claim to have demoed 32-bit Android (VM?) running on 64-bit Linux. What am I missing?

This conversation is becoming completely absurd. First of all, why on earth do you need to run Android in 32bit mode? Just move over an up to date AOSP. You're solving the wrong problem! Your problem was you were trying to avoid porting parts of BB10 to 64-bit, not Android.

Second, I asked you if QNX support mixed mode operation, and now your'e replying with a post from 7 years ago saying that LINUX supports mixed mode. No kidding, Sherlock! We all know Linux can support this (when all the drivers are themselves 64-bit). That's how Android worked during the transition, but it required all the drivers were updated first. And support was added to Linux to make this efficient. And Google did a bunch of work on Android and Linux to make this work efficiently with ARM and Linux.

Linux. The support was added to Linux to make this efficient. To Linux.

Linux.

But that was never the issue, was it? Because for some reason I can't understand, you refuse to just use Linux. So... the issue is can you do this efficiently in QNX and salvage the parts of BB10 that you don't want to port to 64-bit.

Maybe the survey wording can be made simple by limiting this to software features leaving the questions of handset choice and API level for later.

The bottom line is this: Your plan is economically and technically infeasible. You are adamantly opposed to facing that reality and will grasp at anything that even looks like a straw to avoid reality. So all I can say is take this idea to BB and see what they say to you. You're not going to believe any of us on this. Maybe you'll believe them?

OTOH, if someone decides to make the BB10 experience on Linux, I'm all ears and would be happy to help figure that one out.

[bb10adopter111]

OTOH, if someone decides to make the BB10 experience on Linux, I'm all ears and would be happy to help figure that one out.

It would be a big effort, with significant technical challenges and commercial risks, but a Linux-based 5" mobile phone , with BB10-style stock apps and a modern Web browser, for <$1,000 is my dream phone. Most major apps used by businesses already have Linux versions that could be adapted, and there's a huge dev community to fill in the gaps.

The last ten years have shown me why I want a phone that I can own outright, with no obligations to any commercial entities.

I'm estimating 2-5 years before an open source Linux phone will be debugged and ready to support my work. But I'll buy one as soon as it works for calls and the Web with 6+ hours of battery life.

Z10 = BB10 + VKB > iOS + Android

[Dunt Dunt Dunt]

It would be a big effort, with significant technical challenges and commercial risks, but a Linux-based 5" mobile phone , with BB10-style stock apps and a modern Web browser, for <$1,000 is my dream phone. Most major apps used by businesses already have Linux versions that could be adapted, and there's a huge dev community to fill in the gaps.

The last ten years have shown me why I want a phone that I can own outright, with no obligations to any commercial entities.

I'm estimating 2-5 years before an open source Linux phone will be debugged and ready to support my work. But I'll buy one as soon as it works for calls and the Web with 6+ hours of battery life.

Z10 = BB10 + VKB > iOS + Android

Now you have gone and given Don hope.... there is one person willing to pay $1000+ for a new BB10-style modern OS - phone would be extra....

Only 999,999 more to go....

[bb10adopter111]

Now you have gone and given Don hope.... there is one person willing to pay $1000+ for a new BB10-style modern OS - phone would be extra....

Only 999,999 more to go....

I won't pay anything near that for actual BB10, FWIW. I only want to deal with free and open source software on any new platform. No more walled gardens for me.

Z10 = BB10 + VKB > iOS + Android

[DonHB]

Linux. The support was added to Linux to make this efficient. To Linux.

Linux.

But that was never the issue, was it? Because for some reason I can't understand, you refuse to just use Linux. So... the issue is can you do this efficiently in QNX and salvage the parts of BB10 that you don't want to port to 64-bit.

I linked this because of your claim regarding battery life and inefficiencies of switching modes. It seemed to imply that this was not a problem and I assume still is not a problem. Why would QNX have efficiency issues switching modes when Linux does not? I still would like an example of how migration of handsets SoCs to automotive provide savings while the migration of the accompanying software does not.

The bottom line is this: Your plan is economically and technically infeasible. You are adamantly opposed to facing that reality and will grasp at anything that even looks like a straw to avoid reality. So all I can say is take this idea to BB and see what they say to you. You're not going to believe any of us on this. Maybe you'll believe them?

OTOH, if someone decides to make the BB10 experience on Linux, I'm all ears and would be happy to help figure that one out.

I am ready to learn how hardware root of trust is unnecessary for security and the protection of privacy on a mobile device. Otherwise, I would think that what you are proposing would require manufacturing handsets

Maybe you are you just proposing building a launcher that is better than what BlackBerry provided BB Mobile? Are you planning to replace the software stack on something like the Librem 5 or a SailFish like device? How do these companies' customer numbers compare to the numbers of customers remaining on BB10 and BBOS? How do their hardware compare to Samsung A-series handsets?

As unsupported as the apps are on BBW they are available NOW. Can you suggest a source for Android software that is as safe (for security and privacy) as the software is on BBW? I had hoped that Dtek and Cylance would be included to address relying on the Amazon App Store. Would Cylance or the competition be available on your targeted deivice? With a modern Android on a more sticky device than a tablet, developers, may in time, better support Amazon's store. With your proposal how would developers get paid for their work? Is this an OSS project with no expected payback?

Please explain your reality.

[Dunt Dunt Dunt]

I linked this because of your claim regarding battery life and inefficiencies of switching modes. It seemed to imply that this was not a problem and I assume still is not a problem. Why would QNX have efficiency issues switching modes when Linux does not? I still would like an example of how migration of handsets SoCs to automotive provide savings while the migration of the accompanying software does not.

I am ready to learn how hardware root of trust is unnecessary for security and the protection of privacy on a mobile device. Otherwise, I would think that what you are proposing would require manufacturing handsets

Maybe you are you just proposing building a launcher that is better than what BlackBerry provided BB Mobile? Are you planning to replace the software stack on something like the Librem 5 or a SailFish like device? How do these companies' customer numbers compare to the numbers of customers remaining on BB10 and BBOS? How do their hardware compare to Samsung A-series handsets?

As unsupported as the apps are on BBW they are available NOW. Can you suggest a source for Android software that is as safe (for security and privacy) as the software is on BBW? I had hoped that Dtek and Cylance would be included to address relying on the Amazon App Store. Would Cylance or the competition be available on your targeted deivice? With a modern Android on a more sticky device than a tablet, developers, may in time, better support Amazon's store. With your proposal how would developers get paid for their work? Is this an OSS project with no expected payback?

Please explain your reality.

Reality is Reality..... BlackBerry has moved on from smartphones.

Doesn't matter what you want or what you think would be a good idea.... they have moved on and aren't going to look back.


ONLY way this happens is if someone funds it completely and takes all the risk. Because BlackBerry doesn't have the people or money to throw at this, and it's owners (shareholders) are not going to go for going into debit even more than they are... to chase something that has failed four times now - smartphones.

[bb10adopter111]

I linked this because of your claim regarding battery life and inefficiencies of switching modes. It seemed to imply that this was not a problem and I assume still is not a problem. Why would QNX have efficiency issues switching modes when Linux does not? I still would like an example of how migration of handsets SoCs to automotive provide savings while the migration of the accompanying software does not.

I am ready to learn how hardware root of trust is unnecessary for security and the protection of privacy on a mobile device. Otherwise, I would think that what you are proposing would require manufacturing handsets

Maybe you are you just proposing building a launcher that is better than what BlackBerry provided BB Mobile? Are you planning to replace the software stack on something like the Librem 5 or a SailFish like device? How do these companies' customer numbers compare to the numbers of customers remaining on BB10 and BBOS? How do their hardware compare to Samsung A-series handsets?

As unsupported as the apps are on BBW they are available NOW. Can you suggest a source for Android software that is as safe (for security and privacy) as the software is on BBW? I had hoped that Dtek and Cylance would be included to address relying on the Amazon App Store. Would Cylance or the competition be available on your targeted deivice? With a modern Android on a more sticky device than a tablet, developers, may in time, better support Amazon's store. With your proposal how would developers get paid for their work? Is this an OSS project with no expected payback?

Please explain your reality.

Yes, a hardware root of trust is an essential element for any trustable device. But it does not require any particular proprietary implementation.

https://csrc.nist.gov/Projects/Hardware-Roots-of-Trust

Z10 = BB10 + VKB > iOS + Android

[app_Developer]

I linked this because of your claim regarding battery life and inefficiencies of switching modes. It seemed to imply that this was not a problem and I assume still is not a problem. Why would QNX have efficiency issues switching modes when Linux does not? I still would like an example of how migration of handsets SoCs to automotive provide savings while the migration of the accompanying software does not.

(1) The interface between a kernel and its drivers and the graphics subsystem and the hardware are much more chatty than the interface between a kernel and a runtime or other apps. (2) Real work was done in Linux to make this work efficiently on ARM for the transition (but both Google and Apple still pushed to be 64-bit clean because "efficient" is a relative term)

Having typed that, now you'll go off on some non-sequitur about how drivers in QNX run in user space, and I'll have to explain that this is the opposite of what the Palm and Google and Apple teams discovered works well in phones.... yada, yada, yada.

I'm not going to teach you a 5 year SB/SM in CS. And nothing I will say will satisfy your insatiable need to prove that this is possible. And if you're going to try to do that, not from a position of any development or technical experience, but from a bunch of google searches, then honestly isn't this just the Dunning-Kruger thread of CB?

I've lost my ability to care about whether you understand the technical limitations or the business context of what you are proposing. I wish you the best of luck in your effort to get the answer you want from BB.

[DonHB]

Having typed that, now you'll go off on some non-sequitur about how drivers in QNX run in user space, and I'll have to explain that this is the opposite of what the Palm and Google and Apple teams discovered works well in phones.... yada, yada, yada.

Thanks for this. Would you have a link where I can learn more? I am not sure what to search for in this context. Also, anywhere I can learn about how migrating a handset SoC to automotive provides sufficient savings while the accompanying software migration doesn't (or is overhead)?

[Dunt Dunt Dunt]

Thanks for this. Would you have a link where I can learn more? I am not sure what to search for in this context. Also, anywhere I can learn about how migrating a handset SoC to automotive provides sufficient savings while the accompanying software migration doesn't (or is overhead)?

I doubt your going to find "links" to this kind of information... some things just happen.

Who said they are migrating to handset SoC for automotive? Yes the CPU is based on a handset design, but in the end the EUC going to be much larger than any handset SoC. But QNX and Qualcomm have been working together on the Automotive CPUs for years.... there is no migration going on, just the natural update progression

Back in 2014 they were using the SD602A... might actually have been some synergy back then with the Passport's SD601. I suspect BlackBerry lost millions back then on the Passport... but it kept revenue flowing and gave them time to build a software company from almost nothing.

But in 2020 there is no point in loosing millions to generate a little revenue.