1. DonHB's Avatar
    You have not proven anything either. That is the problem.

    I am talking about what can be. You are talking about what you believe things to be without backing up your conjecture with facts.
    08-01-17 02:49 PM
  2. conite's Avatar
    You have not proven anything either. That is the problem.

    I am talking about what can be. You are talking about what you believe thing to be without backing up your conjecture with facts.
    See previous post.
    08-01-17 02:52 PM
  3. DonHB's Avatar
    See previous post.
    Well at least you agreed that an Android app requires no more access than a native app. Things have progressed.
    08-01-17 02:54 PM
  4. conite's Avatar
    Well at least you agreed that an Android app requires no more access than a native app. Things have progressed.
    I never stated otherwise.
    08-01-17 02:54 PM
  5. DreadPirateRegan's Avatar
    I think once BlackBerry realizes it's mistake with going Crapdroid, BB10 will make a triumphant return. It's foolish to ignore such a powerful OS that they built from the ground up.

    Posted via CB10
    I'm still with you brother, even if they laugh at US!
    Love that big 1x1 ratio screen. Even though 4.5 inches my friends think it's larger screen then their six inch screened phones. Hah...

    Posted via CB10
    08-01-17 03:11 PM
  6. DonHB's Avatar
    I never stated otherwise.
    Good for you.
    08-01-17 03:20 PM
  7. conite's Avatar
    You also never stated it in the affirmative.
    We've never talked about an individual app. We've talked about the Android Runtime environment which needs to constantly negotiate between android apps and the BB10 OS - handling notifications, access to services, providing alternatives to the google framework, etc. Big, big difference.
    BigBadWulf likes this.
    08-01-17 03:25 PM
  8. app_Developer's Avatar
    We've never talked about an individual app. We've talked about the Android Runtime environment which needs to constantly negotiate between android apps and the BB10 OS - handling notifications, access to services, providing alternatives to the google framework, etc. Big, big difference.
    Bingo. Apps on mobile devices have very restricted access to resources . This is important for security, battery life, etc.

    A runtime that has to host apps needs much more access and much tighter integration. This is so the runtime can provide all the capabilities and APIs that it must provide to apps, and do this in a performant way that doesn't slaughter the user's battery.

    The idea of a full Android runtime (even sans GPS) is not possible.
    BigBadWulf likes this.
    08-01-17 04:10 PM
  9. stlabrat's Avatar
    Common Sense plus conservative estimates.

    As I said above, full-blown development was 10 times that figure and required 10 million device sales per year just to break even.
    30 to 50 million just for support is a bit high...here are 6 non-iOS/droid OS currently still active, I don't see some of those guys spend 30-50 million (if they have in the bank)...https://en.softonic.com/articles/6-terrific-smartphone-operating-systems-that-are-not-android%2Bhow+much+to+support+smart+phone+os&num=1 &client=safari&rls=en&hl=en&prmd=ivns&strip=1&vwsr c=0]6 Terrific Smartphone Operating Systems that are Not Android[/url]
    In addition, BB10 is much close nit compare to droid, you don't need security patch every month (just see how many month no update, it still ok somewhat). ROM estimate for full support, say head count of 20ish (just support) at 100K per head, that still a managable amount (x2.5 if you wish add on overhead). The SDK is different animal, it really need some attention if you are going to revamp to next level, That could be a money pit if no strong PM on hand... with 30-50 million support? I would get AI (security patch and some update on network protocol, no hardware support). It is not droid that full of holes, BB10 is much less "hole-ly". IMHO. (the problem is not money, but the will of the key players- there are enough "investor" just want license everything and collect money monthly... not doing anything).
    08-01-17 04:17 PM
  10. DonHB's Avatar
    Sigh. I give up. We don't seem to have a common knowledge base to work from. Cheers.
    I think the problem is that you believe the Player provides a means for a guest OS to run. That it is similar to Virtual Box or VMware. Dalvik's purpose in Android is to abstract away the instruction set of the underlying hardware making one APK runnable (JNI voids this) on various architectures such as ARM, x86/64 and PowerPC. Therefore Dalvik passes operating system functionality to the underlying OS instead of running a full OS. Though, in VMware and similar VMs, drivers can be used to do something similar.
    08-01-17 04:25 PM
  11. conite's Avatar
    I think the problem is that you believe the Player provides a means for a guest OS to run. That it is similar to Virtual Box or VMware. Dalvik's purpose in Android is to abstract away the instruction set of the underlying hardware making one APK runnable (JNI voids this) on various architectures such as ARM, x86/64 and PowerPC. Therefore Dalvik passes operating system functionality to the underlying OS instead of running a full OS. Though, in VMware and similar VMs, drivers can be used to do something similar.
    /blackberry-10-os-f269/like-see-one-more-bb10-device-1101450/index12.html#post12977809
    08-01-17 05:03 PM
  12. app_Developer's Avatar
    I think the problem is that you believe the Player provides a means for a guest OS to run. That it is similar to Virtual Box or VMware. Dalvik's purpose in Android is to abstract away the instruction set of the underlying hardware making one APK runnable (JNI voids this) on various architectures such as ARM, x86/64 and PowerPC. Therefore Dalvik passes operating system functionality to the underlying OS instead of running a full OS. Though, in VMware and similar VMs, drivers can be used to do something similar.
    One of the many things that the Android runtime must do is spin up and orchestrate processes, as needed, to service running activities and services.

    How can you do that within a BB10 app?

    What happens when BB10 (because of the serious design flaw in its memory model) has to kill your runtime app because the user switched to some other high mem usage app, like the browser? Are you going to restart the entire Android stack every time a user switches back to an Android app?

    Somewhere between the extremes of a full virtualized machine and what you can do inside a mobile app is the reality of running something like the Android runtime.

    Look at it another way, if 3rd party BB10 apps could do everything a runtime needs to do, that would be a major security hole. Big enough to drive a truck through.
    BigBadWulf likes this.
    08-01-17 05:03 PM
  13. DonHB's Avatar
    What happens when BB10 (because of the serious design flaw in its memory model) ...
    Please explain the flaw? Did it exist pre 10.3.3?

    Look at it another way, if 3rd party BB10 apps could do everything a runtime needs to do, that would be a major security hole. Big enough to drive a truck through.
    I asked this question of Conite:

    In what way does an Android app need more access to the system then a native app?
    08-01-17 05:22 PM
  14. app_Developer's Avatar
    Please explain the flaw? Did it exist pre 10.3.3?

    I asked this question of Conite:

    In what way does an Android app need more access to the system then a native app?
    Your question doesn't make sense to me. We are talking about what a runtime needs, not what an app needs.

    A runtime needs much more than an app. Like the example I just gave you about process orchestration. Apps can't do that.

    As for the flaw: BB decided to use a very simplistic memory model like what you have on desktop/laptop computers. The engineers at Palm, Android, Microsoft and Apple all figured out you can't do that on phones because phones can't write dirty pages to disk. Somehow the BB10 team missed that fact, even though the BBOS team no doubt knew that. As I understand it, the teams were kept totally separate and QNX had never run on a device like a phone.

    The implication is that when under memory pressure BB10 has no options other than to kill apps. It's a very rudimentary and naive way to manage memory. Android has a much more sophisticated and well thought out approach.
    08-01-17 05:30 PM
  15. DonHB's Avatar
    Your saying BB10 doesn't have virtual memory? Actually, it does. Also, the IPC and userland functionality of the OS would be issues in Linux, but not Neutrino.
    Last edited by DonHB; 08-01-17 at 05:49 PM. Reason: Acting like conite -- removed lack of time to substantiate.
    08-01-17 05:38 PM
  16. app_Developer's Avatar
    Your saying BB10 doesn't have virtual memory? Actually, it does. Also, the IPC and userland functionality of the OS would be issues in Linux, but not Neutrino.
    No, I did not say it lacks virtual memory. I said it can't actually write out dirty pages. You can't do that on the type of memory used in these phones. The phone wouldn't last more than a few weeks.

    People who make phone operating systems know this. The BB10 team did not. The is not an issue in cars or nuclear power plants, particularly when you don't have 3rd party apps.

    You can test this yourself on a BB10 device. Open a bunch of apps. Pretty soon the OS starts killing apps. It has no choice. On Android you can open dozens of apps and this won't happen.
    Troy Tiscareno likes this.
    08-01-17 05:47 PM
  17. DonHB's Avatar
    No, I did not say it lacks virtual memory. I said it can't actually write out dirty pages. You can't do that on the type of memory used in these phones
    Has Android changed since this was written.
    08-01-17 05:59 PM
  18. DonHB's Avatar
    No, I did not say it lacks virtual memory. I said it can't actually write out dirty pages. You can't do that on the type of memory used in these phones. The phone wouldn't last more than a few weeks.
    If it can't write dirty pages there is no virtual memory.
    08-01-17 06:06 PM
  19. app_Developer's Avatar
    If it can't write dirty pages there is no virtual memory.
    No, that's not true. Virtual memory just means that processes see a virtual address space that is mapped to physical pages (usually by hardware). QNX supports that just like any other modern kernel.

    Windows CE, Windows 10 on phones, Android, iOS, PalmOS, WebOS (on phones) are all example of operating systems that have virtual memory but are configured to not swap out dirty pages.

    BB10 is also configured to not swap out dirty pages. However, the problem is they designed their process and memory as if it could. That's a huge mistake and one that would be difficult to fix now. But it doesn't matter because few people care anymore.
    08-01-17 06:11 PM
  20. app_Developer's Avatar
    Has Android changed since this was written.
    You'll notice the answer with 4 up votes links to good articles that describe how this works in Android.

    The answer with zero votes has incorrect information, which is probably why it has zero up votes. I'd actually down vote it after reading it, but I'm too nice.

    Android can and does kill and restart underlying processes. The brilliance of their model is that this doesn't require killing and restarting the app (the collection of services and activities). It's that decoupling that is important. iOS has something similar. So does Windows. So did WebOS. So did PalmOS before it.
    08-01-17 06:15 PM
  21. DonHB's Avatar
    You are right about mapping of memory as virtual memory.

    I think you are talking about the lack of TRIM and write endurance of Flash memory used in phones. Where can I find out more about this issue of memory management in BB10?

    Thanks.
    08-01-17 06:25 PM
  22. app_Developer's Avatar
    Where can I find out more about this issue of memory management in BB10?
    .
    There isn't much to read in the BB10 docs, because there isn't much to say. They just used straight up normal semantics from a process on any normal *nix OS. You start a process (an app) and you get a virtual memory space. As you allocate in that space, pages get mapped for you (as you would expect). When there is memory pressure you get a signal, and then if the OS needs to reclaim space you're done. Normal stuff that you would expect on a server that is out of swap space. (effectively phones start up with avail swap space at 0. That's a useful way to think about this)

    What's more interesting to read is what the other teams did to make all of this work much better for phones, especially ones where users are installing an arbitrary number of 3rd party apps. You can then contrast what Apple, Google, Palm and Microsoft all did compared to the simple naive approach in BB10.

    There's a lot of content around this. A decent start is here on the process model:
    https://developer.android.com/guide/...lifecycle.html

    Also search for application cycle or memory management in Apple's WWDC videos from like 2010-2015 or so in that range.
    Last edited by app_Developer; 08-01-17 at 08:20 PM.
    BigBadWulf, stlabrat, iled and 1 others like this.
    08-01-17 08:05 PM
  23. eshropshire's Avatar
    Blackberry posted to there developers around 2 years ago that there would be no changes to the ART. Even if the changes you want did not directly violate the terms of Blackberry's OHA agreement the changes would violate the spirit of the agreement. BlackBerry Limited's relationship with Google would be finished.

    BlackBerry Limited as an enterprise software company with a major focus on mobile and IoT needs a great working relationship with Google. BlackBerry Limited gets absolutely ZERO from updating ART. They stand to loose a lot.
    08-01-17 11:38 PM
  24. dpgo's Avatar
    Why is BB going to do anything for BB10 ever again that doesn't produce significant profit? If people want things from Android like Android Player, there's you know, Android OS....
    Just because they owe support to users and companies, as customers the only possible revenge is not buying their new devices.
    Thinking just in short term money is not good and IMO
    This is a PalmOS situation, it was bad for them and will be bad for BB.

    As user I don't care how they divide the company, how departments are configured, etc..

    If you don't respect your users, you cannot expect to be respected.

    With the payment of a couple of executives we could a proper and updated OS


    Posted via CB10
    08-02-17 09:54 AM
  25. conite's Avatar
    Just because they owe support to users and companies, as customers the only possible revenge is not buying their new devices.
    Thinking just in short term money is not good and IMO
    This is a PalmOS situation, it was bad for them and will be bad for BB.

    As user I don't care how they divide the company, how departments are configured, etc..

    If you don't respect your users, you cannot expect to be respected.

    With the payment of a couple of executives we could a proper and updated OS


    Posted via CB10
    How valuable are you if you haven't bought a single BlackBerry device built after 2014?

    What is a "proper" update? Since their hands are tied on the Android Runtime and 3rd party developers have left in droves, would a few more browser certificates satisfy you?
    08-02-17 10:24 AM
314 ... 10111213

Similar Threads

  1. Returning to BB & PKBs! Priv or KEYone?
    By warrigal in forum BlackBerry KEYone
    Replies: 33
    Last Post: 03-17-17, 03:20 AM
  2. LONGSHOT: Any one know the next partner should TCL pull out?
    By d987654321 in forum General BlackBerry News, Discussion & Rumors
    Replies: 17
    Last Post: 03-04-17, 03:55 PM
  3. Transferring from Leap to Dtek50 - advice?
    By buon1977 in forum BlackBerry DTEK50
    Replies: 14
    Last Post: 03-04-17, 06:44 AM
  4. Bluetooth to play through BB
    By MoxBerry in forum Ask a Question
    Replies: 1
    Last Post: 02-28-17, 08:11 AM
  5. Why can I not trasfer data from a Z30 to A Leap-AC01
    By CrackBerry Question in forum Ask a Question
    Replies: 1
    Last Post: 02-27-17, 06:08 PM
LINK TO POST COPIED TO CLIPBOARD