RIM shows PlayBook tablet, will not undercut iPad in price

135

Comments

  • Reply 41 of 88
    nhtnht Posts: 4,522member
    Quote:
    Originally Posted by samab View Post


    We are talking about resource constraint environment with limited RAM and CPU speed. A couple of megabytes saved here and there may not mean much on the desktop, but on a cell phone that may be a lot.



    A dual core 1Ghz cell phone with 512MB+ of RAM and gig of storage? Are you kidding? For an RTOS developer that's not constrained at all. In constrained environments we don't even write C++ but C. No helpful abstraction layers but code close to the metal.



    The bottom line is that Apple, Google and Microsoft smartphone operating systems are richer in capability than the QNX solution but actually CAN run on single core ARMs...whereas RIM states your "superior" RTOS based smartphone OS cannot run until they have a dual core A9 based BB phone.



    So whatever efficiency advantages that QNX brought to the table is completely downed by using Adobe code as part of the application framework.
  • Reply 42 of 88
    anonymouseanonymouse Posts: 6,857member
    Quote:
    Originally Posted by samab View Post


    The demos are showing a promising start so far.



    Well, you said do what Palm did.
  • Reply 43 of 88
    nhtnht Posts: 4,522member
    Quote:
    Originally Posted by Dick Applebaum View Post


    I understand the advantages of a RTOS... what I don't understand is what user benefits it will bring to a smart phone or even today's tablets.



    Please amplify.



    Nothing. There are no hard real time requirements for user application processing. Any RT requirements are handled by the RTOS in the baseband processor.



    It's not like you're running any real time guidance and navigation apps on your iphone that have hard 50 ms timing requirements that must be met or your missile flies off course...
  • Reply 44 of 88
    dreyfus2dreyfus2 Posts: 1,072member
    Quote:
    Originally Posted by nht View Post


    Arguably this isn't any worse than Silverlight for WP7 but MS controls both the OS and ui engine. Half of BlackBerry's framework is owned by Adobe. I expect this makes them far less agile than Apple, Google and Microsoft all of which own all pieces of the puzzle.



    You mean putting all eggs in the basket of a company that promises a mobile version of their toy environment since almost three years without ever getting there (their actual development effort can be summarized as: waiting for the hardware to get powerful enough to run our junk as is)... is not a good idea



    Gosh, people are demanding here
  • Reply 45 of 88
    Quote:
    Originally Posted by samab View Post


    Users benefit from having a system that has a smaller footprint from the start.



    That's why the praybook needs a cortex a9 and a gig of ram.
  • Reply 46 of 88
    Quote:
    Originally Posted by nht View Post


    A dual core 1Ghz cell phone with 512MB+ of RAM and gig of storage? Are you kidding? For an RTOS developer that's not constrained at all. In constrained environments we don't even write C++ but C. No helpful abstraction layers but code close to the metal.



    The bottom line is that Apple, Google and Microsoft smartphone operating systems are richer in capability than the QNX solution but actually CAN run on single core ARMs...whereas RIM states your "superior" RTOS based smartphone OS cannot run until they have a dual core A9 based BB phone.



    So whatever efficiency advantages that QNX brought to the table is completely downed by using Adobe code as part of the application framework.



    Well said - RIM tying their destiny to adobe's software is moronic.



    If they should learn anything from apple it's the importance of controlling the entire software stack.
  • Reply 47 of 88
    In co-CEO-speak: It means we have lots of categories and are just beginning????
  • Reply 48 of 88
    alfiejralfiejr Posts: 1,524member
    so ... RIM is promising a lot of very fast work. but if they can't meet their own announced schedule soon, it is going to really hurt them. in this hyper competitive market they can't get away with stringing everyone along thru the next year with just bits and pieces of software and a half-done new PlayBook for sale. didn't they learn that from the big BB Storm flop?
  • Reply 49 of 88
    nhtnht Posts: 4,522member
    Quote:
    Originally Posted by dreyfus2 View Post


    There is zero difference between a RTOS and an non-realtime OS on a tablet or phone, if the regular OS has been slimmed down to only support the functionality required on a device.



    This is untrue. A RTOS is defined as a OS that can provide deterministic timing. There are fast RTOS and slow ones. A general purpose OS can outperform a slower RTOS.



    The performance of an RTOS is generally measured by it's worst case task response time...not best case or even average case throughput. This is because you typically won't use an RTOS unless you have a hard Real Time requirement that must be met and you analyze performance based on that worst case time (using RMA).



    So the difference is an RTOS will guarantee that a task will happen within it worst case time including all preemption latency, context switch time, yada yada yada.



    Quote:

    There is also no general speed advantage (with e.g. processing messages) when comparing a process on a RTOS with one scheduled to run with the highest priority under a regular OS.



    This depends on how the scheduler is designed. Different scheduler algorithms produce different results for when processes get preempted. Many RTOS will starve lower priority processes to insure critical tasks meet their time deadline. Most GP OS have some kind of fairer scheduler.



    Quote:

    The only real benefit (a theoretical one and one that does not affect the user at all) is that RTOSs can switch off unneeded parts of themselves dynamically, e.g. you could deploy the very same version of an OS to different devices with different capabilities and the system could optimize itself for each of them. Apple has to do this the hard way by providing different downloads for different devices.



    Ah...no. I wish this was a basic characteristic of an RTOS because I spent too many late nights helping hand tune VxWorks kernels in a past life. It was seriously un-fun and I wasn't the poor schmuck actually assigned to do this but the app developer making sure that something critical didn't get hosed with a specific configuration change to improve performance.
  • Reply 50 of 88
    samabsamab Posts: 1,953member
    Quote:
    Originally Posted by nht View Post


    A dual core 1Ghz cell phone with 512MB+ of RAM and gig of storage? Are you kidding? For an RTOS developer that's not constrained at all. In constrained environments we don't even write C++ but C. No helpful abstraction layers but code close to the metal.



    The bottom line is that Apple, Google and Microsoft smartphone operating systems are richer in capability than the QNX solution but actually CAN run on single core ARMs...whereas RIM states your "superior" RTOS based smartphone OS cannot run until they have a dual core A9 based BB phone.



    So whatever efficiency advantages that QNX brought to the table is completely downed by using Adobe code as part of the application framework.



    That's like saying 512kb is enough.



    It's not like they can't run it on single core --- the Playbook has been demoing with one hand tied behind their back.
  • Reply 51 of 88
    dreyfus2dreyfus2 Posts: 1,072member
    Quote:
    Originally Posted by nht View Post


    This is untrue. A RTOS is defined as a OS that can provide deterministic timing. There are fast RTOS and slow ones. A general purpose OS can outperform a slower RTOS.



    Maybe my choice of words was poor... I basically meant the same thing. There is no way to say that any given RTOS will always outperform a general purpose OS at any given task. E.g. the deterministic timing could enforce the availability of CPU cycles for a task that a general purpose OS is holding back for valid reasons.



    Quote:
    Originally Posted by nht View Post


    Ah...no. I wish this was a basic characteristic of an RTOS because I spent too many late nights helping hand tune VxWorks kernels in a past life. It was seriously un-fun and I wasn't the poor schmuck actually assigned to do this but the app developer making sure that something critical didn't get hosed with a specific configuration change to improve performance.



    Thanks for the correction. This was actually something we were told in university... so, you say there are RTOSs that do that and others that don't, or is this rubbish altogether... Just trying to wrap my head around what you are saying: a RTOS switching off parts of the kernel because there is hopefully no need for them (commonly because there is no hardware that makes use of them) can cause problems for software... Not at all doubting what you are saying, but I am afraid I'm not really getting it yet.
  • Reply 52 of 88
    Quote:
    Originally Posted by Alfiejr View Post


    so ... RIM is promising a lot of very fast work. but if they can't meet their own announced schedule soon, it is going to really hurt them. in this hyper competitive market they can't get away with stringing everyone along thru the next year with just bits and pieces of software and a half-done new PlayBook for sale. didn't they learn that from the big BB Storm flop?



    Yeah! And from a lot of newly acquired companies that aren't integrated into RIM.



    RIM can't yet commit to specific hardware (CPU & GPU), price point, battery life, delivery date...



    Compare that to the intro of the iPhone. SJ showed a working demo of the OS and the limited number of apps on the iPhone. Made firm commitments on specs, price, battery, delivery date. Then, to meet the delivery deadline, he had to pull experienced OS X developers and repurpose them to iOS for 6 months. Experienced, highly-motivated people, used to working with each other, directed to perform a few, well-defined tasks. No outside software dependencies. No outside Developer interfaces to dissipate resources.



    I knew most of the developers of the original 1984 Mac Software/Hardware team -- less than 20 people, working "100 hours a week and Loving it". All under the focused direction of a super perfectionist who knows how to motivate people.



    I suspect the same sort of team was in place to assure that iOS 1 delivered the goods.





    With the stumbling, rambling, buffoonery that RIM has exhibited since the September PlayBook announcement -- I see zero chance of RIM making this happen before June 2011. Then, they will have a 1.0 release, with expected bugs, etc. and limited choice of apps.



    I suspect that Microsoft could have a tablet version of WP7 in that timeframe -- with a good mix of basic apps. Android's Tablet OS version will be available with apps. HP, likely, will have a WebOS Tablet with apps.



    Who is going to buy a PlayBook? Why?



    .
  • Reply 53 of 88
    Quote:
    Originally Posted by samab View Post


    That's like saying 512kb is enough.



    It's not like they can't run it on single core --- the Playbook has been demoing with one hand tied behind their back.



    Maybe they should untie that hand and use it to cover a certain mouth...
  • Reply 54 of 88
    hill60hill60 Posts: 6,992member
    Quote:

    However, just this spring Lazaridis claimed that touch-only phones like the iPhone aren?t that popular, and that most of the people buying touchscreen phones were subsequently going back to phones with hardware keyboards, like those that made RIM ?famous.?



    What an idiot, the iPhone isn't a BB Storm.



    Basing claims on BB users burned by the Storm and preferring to upgrade to a Bold or a Curve over a Torch does not equate to what other platform users do.



    There are a lot of BB users who were taken in by the Storm hype who will not even look at the Torch, they often have no choice but BB so go back to the keyboard.



    The Storm was probably up there with the worst phones ever made, the Storm 2 (Where "We've fixed it this time".) was marginally better, presenting the Torch to twice burned people is beyond a joke.



    I think RIM is in for some hard times ahead.
  • Reply 55 of 88
    kevtkevt Posts: 195member
    Quote:
    Originally Posted by addabox;1765423[B


    ]I'm thinking that maybe Palm is the real point of comparison for RIM going forward. They managed to get a well received and by all reports pleasant to use OS out the door, but broke compatibility with their installed user base. Thus, the lack of apps and the comparatively lackluster developer environment couldn't generate enough buzz and goodwill to break through new platform inertia.[/B]



    MS, of course, has done something similar with WP7, but MS has a lot more going on (and many more revenue streams) than just a mobile operating system and can use that to help prop things up until if and when their new phone OS gets some critical mass.



    So if RIM has to basically start over with a new OS, then they have to pretty much start over in the marketplace. Sure, there's some product loyalty and name recognition, but the fabled BB installed user base lock-in behemoth pretty much counts for nothing. An army of Palm users didn't do the Pre much good, we'll see if QNX phones can do any better.





    Up to a point there is a comparison. However (1) RIM's Blackberry installed user base is much larger than Palm's had become. (2) Palm's users and developers were pretty 'hacked off' with Palm after years of decline, false promises made of different paths that Palm was going to take with their OS.



    The army had very little sense of loyalty to Palm, I suspect Blackberry users may have more.
  • Reply 56 of 88
    hirohiro Posts: 2,663member
    Quote:
    Originally Posted by samab View Post


    Users benefit from having a system that has a smaller footprint from the start.



    An RTOS does not guarantee a smaller footprint, it only guarantees real-time schedulability. The OS X kernel is only a few MB in size, everything else is GUI, drivers and additional desktop OS support. Adding all that stuff to QNX will make it have a comparable footprint to iOS.



    You may be thinking of embedded OS versions of QNX, which are nowhere near capable enough for a general purpose user machine. The embedded space is also realtime, but everything except what that device's board is removed, and nothing other than the paltry hardware is supported.



    Sure toasters and microwaves have small embedded OSes and QNX has flavors for them, but those tiny flavors have no bearing or influence on something that has to support as much generalized computation and user centric I/O as a tablet OS.



    Quote:
    Originally Posted by samab View Post


    We are talking about resource constraint environment with limited RAM and CPU speed. A couple of megabytes saved here and there may not mean much on the desktop, but on a cell phone that may be a lot.



    Not on a cellphone with several hundreds of megabytes of space. Especially when as I mentioned, the size of the OS X and QNX kernel isn't very big. it is all the stuff you have to add to make it a general purpose user centric device that makes an OS footprint relatively large.
  • Reply 57 of 88
    samabsamab Posts: 1,953member
    Quote:
    Originally Posted by Hiro View Post


    An RTOS does not guarantee a smaller footprint, it only guarantees real-time schedulability. The OS X kernel is only a few MB in size, everything else is GUI, drivers and additional desktop OS support. Adding all that stuff to QNX will make it have a comparable footprint to iOS.



    You may be thinking of embedded OS versions of QNX, which are nowhere near capable enough for a general purpose user machine. The embedded space is also realtime, but everything except what that device's board is removed, and nothing other than the paltry hardware is supported.



    Sure toasters and microwaves have small embedded OSes and QNX has flavors for them, but those tiny flavors have no bearing or influence on something that has to support as much generalized computation and user centric I/O as a tablet OS.







    Not on a cellphone with several hundreds of megabytes of space. Especially when as I mentioned, the size of the OS X and QNX kernel isn't very big. it is all the stuff you have to add to make it a general purpose user centric device that makes an OS footprint relatively large.



    But there is no difference between the embedded version of QNX and the desktop version of QNX --- which has always exist for the last 30 years (i.e. web browser on a floppy disc).
  • Reply 58 of 88
    hirohiro Posts: 2,663member
    Quote:
    Originally Posted by dreyfus2 View Post


    None and nothing. Because this assumption is based on the unproven premise that iOS contains things it does not need. It is not OS X, it is much lighter (e.g. lacks tons of drivers and interfaces). There is zero difference between a RTOS and an non-realtime OS on a tablet or phone, if the regular OS has been slimmed down to only support the functionality required on a device. There is also no general speed advantage (with e.g. processing messages) when comparing a process on a RTOS with one scheduled to run with the highest priority under a regular OS.



    The only real benefit (a theoretical one and one that does not affect the user at all) is that RTOSs can switch off unneeded parts of themselves dynamically, e.g. you could deploy the very same version of an OS to different devices with different capabilities and the system could optimize itself for each of them. Apple has to do this the hard way by providing different downloads for different devices.



    Quote:
    Originally Posted by Dick Applebaum View Post


    Thank you! I understand! Someone like Apple who makes an universal OS for a wide range of hardware would benefit from a RTOS that could scale itself to its environment (rather than being manually scaled and deployed).



    .



    Not really. When you want optimization in size or functionality, you bake it in from the start. Yes, you compile the OS exactly like you want it. Embedded OSes like QNX come with lots of configurability in the build phase, and those build tools are really what the Embedded space buyers pay for, not the OS itself.



    Embedded devices are developed with as little changing after the fact as possible, maybe never. You don't rely on an automated in the field OS self-reconfiguration unless you want to kill your reputation.
  • Reply 59 of 88
    hirohiro Posts: 2,663member
    Quote:
    Originally Posted by mjtomlin View Post


    iOS is in fact OS X, it is NOT Mac OS X. Operating systems are not defined by drivers or interfaces, but rather architecture. It is a lot smaller in footprint, because all the hardware support can be trimmed down to just several components and remain fixed.



    Wrong iOS has the same basic architecture as OS X. Just peel off the Java and Cocoa layers, put on CocoaTouch in their place. Everything below CocoaTouch is OS X kernel and services, minus the service parts that aren't needed in iOS devices.



    The beauty of iOS is that the kernel Hardware Abstraction Layer is pretty much the only part that needs custom porting to a completely different chip architecture, like moving from PPC to Intel, or Intel to ARM. All the rest is built directly on top of the kernels Hardware Abstraction Layer, meaning you compile and build to the platform, but since you aren't using platform dependencies at the higher levels, there's no porting to be done.
  • Reply 60 of 88
    hirohiro Posts: 2,663member
    Quote:
    Originally Posted by samab View Post


    But there is no difference between the embedded version of QNX and the desktop version of QNX --- which has always exist for the last 30 years (i.e. web browser on a floppy disc).



    And there is no difference between the OS X kernel and the iOS kernel, which has been developed off MachOS since the late 1970's, making the tech tree around 30+ years mature. Got another poorly crafted comparison we can break?
Sign In or Register to comment.