[Blacklatino]

Yeah I'd be curious to see a breakdown of QNX revenue and some details on how they actually generate money.

Posted via CB10

Same here- if generating any at all. If so, maybe use some for marketing. WIIFT (What's In It For Them). BlackBerry- whether they accept it or not, are still at the stage of answering the "why" factor (question) from former and potentially new consumers in regards to switching or staying with Android or Apple. Some additional marketing for better brand recognition prior to the release of the pending devices can't hurt at this point.

[Jerry A]

It's not the microkernel design that is the issue. I don't think that makes much of a practical difference. The RT scheduling strategy, though, is a bad idea IMO.

The issue is the rest of the OS. The idea that every app is a certain process doesn't work in phones. The lifecycle of the app really has to distinct from the lifecycle of the underlying process(es). This idea is very well developed in Android, and flat out doesn't even exist in BB10. That, in turns, leads to a very poor memory model.

And then you have the graphics libs and all other frameworks and APIs presented to apps. All of these are part of a complete OS, and areas where the QNX team had little experience and poor designs.

In all fairness, I thought the TAT team was responsible for building the Cascades API and "smartphone" bits on top of the kernel and core OS which QNX provides. No different than the KDE and GNOME environments (ie they don't work on the Linux kernel).

Blaming the QNX team for enhancing and maintaining the embedded OS seems (not you app_Developer) smacks of pure revisionism.

Tossing around Dodge's name, doubly so, since few around here knew who he was before his retirement was announced.

How come we don't throw shade on Vivek for taking so long to get BB10 out the door and in a better functioning state? (PS - We shouldn't - no one knows exactly what was going on behind closed doors)

[app_Developer]

In all fairness, I thought the TAT team was responsible for building the Cascades API and "smartphone" bits on top of the kernel and core OS which QNX provides. No different than the KDE and GNOME environments (ie they don't work on the Linux kernel).

Blaming the QNX team for enhancing and maintaining the embedded OS seems (not you app_Developer) smacks of pure revisionism.

Tossing around Dodge's name, doubly so, since few around here knew who he was before his retirement was announced.

How come we don't throw shade on Vivek for taking so long to get BB10 out the door and in a better functioning state? (PS - We shouldn't - no one knows exactly what was going on behind closed doors)

TAT was responsible for Cascades. But my understanding is that the team had committed to Qt even before TAT was acquired. In any case, other frameworks likes the inter app messaging and location services were all folks from the QNX team.

The process model was certainly not TAT. That was clearly QNX, wouldn't you agree? That was a huge miss and showed the inexperience of the team. This was all under Dodge's watch in his role at BlackBerry post acquisition.

When it comes to the things QNX is good at, though, Dodge really was the visionary. I don't think those are easy shoes to fill, regardless of whether people on CB know who he is.

[Bluenoser63]

It's not the microkernel design that is the issue. I don't think that makes much of a practical difference. The RT scheduling strategy, though, is a bad idea IMO.

The issue is the rest of the OS. The idea that every app is a certain process doesn't work in phones. The lifecycle of the app really has to distinct from the lifecycle of the underlying process(es). This idea is very well developed in Android, and flat out doesn't even exist in BB10. That, in turns, leads to a very poor memory model.

And then you have the graphics libs and all other frameworks and APIs presented to apps. All of these are part of a complete OS, and areas where the QNX team had little experience and poor designs.

I disagree. As long there is a communications component between apps, this provides security and isolates each app. It also allows for an app to be restarted without effecting the OS or the other app. The fact that Android slows down when an update is being downloaded shows this flaws in tying the process to the OS and not making it's own. Android will get around to fixing this someday.

They actually had a good design, or are you saying that Qt is a poor design. Cascases is mostly a wrapper for Qt. If you took some time to go deep into the libs in Momentics, you will understand that most of the stuff was already designed by others. Almost most of the SDK was designed by the Qt team and not BlackBerry, BlackBerry provided Cascades by purchasing AT. And you can't tell me that they didn't know how to write good GUI element. BlackBerry just put the reigns on their creatively and went all Enterprise on them so they left.

[app_Developer]

I disagree. As long there is a communications component between apps, this provides security and isolates each app. It also allows for an app to be restarted without effecting the OS or the other app. The fact that Android slows down when an update is being downloaded shows this flaws in tying the process to the OS and not making it's own. Android will get around to fixing this someday.

No, no, you're talking about something totally different. Of course apps run in user processes. That's obvious and true for all OSes since forever basically.

I'm saying that an app shouldn't be tied to the lifecycle of a single process. Activities and services on Android aren't tied to a single long running process. The OS can start and stop underlying processes while an app's activities and services continue where they left off. This is why Android can run with less RAM and why you don't have the 8 open apps and we start killing apps behavior.

You can have 10 apps running on your android phone and, at any given time, fewer than 10 or even more than 10 processes running those apps. Android (and iOS and Windows) manage that much more elegantly than BB10 is able to. This is why apps suddenly disappear in BB10 and lose their state. It's also why BB10 can't even run properly with 1G of RAM.

They actually had a good design, or are you saying that Qt is a poor design. Cascases is mostly a wrapper for Qt. If you took some time to go deep into the libs in Momentics, you will understand that most of the stuff was already designed by others. Almost most of the SDK was designed by the Qt team and not BlackBerry, BlackBerry provided Cascades by purchasing AT. And you can't tell me that they didn't know how to write good GUI element. BlackBerry just put the reigns on their creatively and went all Enterprise on them so they left.

I'm saying what is provided by Qt and Cascades is extremely primitive compared to what we have in iOS, and even compared to what we have in Android or Windows. Actually, it's really not even close when comparing iOS core graphics, core animation, uikit, spritekit, metal, etc to what BB10 offers. Qt was readily available and free, but that doesn't mean it was comparable to the start of the art in 2013. It was readily available and free.

But again, it's not just the graphics stuff, all the rest of the frameworks and APIs are similarly primitive in BB10 when compared with Windows, Android, and iOS.

[Troy Tiscareno]

" Oversold "? ? Not in the least. Many gadgets you use already employ QNX including the Apple infotainment system.

Apple doesn't make an "Apple Infotainment system." They do make an app called Car Play that uses the car's existing digitizer and display to run apps remotely from an iPhone, but that has little to do with QNX, except that Car Play is an app that runs on a number of platforms, including Linux, Windows, and QNX For Cars.

But the only consumer "gadget" that uses QNX is a BB10 phone. Otherwise, QNX is mostly middleware for cars and control software for industrial uses - virtually no consumer-based applications for it to date.

[Uzi]

Apple doesn't make an "Apple Infotainment system." They do make an app called Car Play that uses the car's existing digitizer and display to run apps remotely from an iPhone, but that has little to do with QNX, except that Car Play is an app that runs on a number of platforms, including Linux, Windows, and QNX For Cars.

But the only consumer "gadget" that uses QNX is a BB10 phone. Otherwise, QNX is mostly middleware for cars and control software for industrial uses - virtually no consumer-based applications for it to date.

I still remember your post about RTOS ,good explain why it's not good for mobile os

[app_Developer]

I still remember your post about RTOS ,good explain why it's not good for mobile os

If you find that can you post a link? I also think RT scheduling is a bad idea for phones. I've talked to people from Palm, Apple and Microsoft who all think BB was rather naive to think RT was a good idea in a modern phone. I'd love to read Troy's take on that subject.

If you think about it, RT makes perfect sense for other applications. It makes very little sense at all for this one.

[Uzi]

If you find that can you post a link? I also think RT scheduling is a bad idea for phones. I've talked to people from Palm, Apple and Microsoft who all think BB was rather naive to think RT was a good idea in a modern phone. I'd love to read Troy's take on that subject.

If you think about it, RT makes perfect sense for other applications. It makes very little sense at all for this one.

IMO, you don't have a very good understanding.

Google could have bought QNX for pocket change in 2010 (much like RIM actually did). And of course Google was aware of their existence. Google also could have built Android on top of LinuxRT (the RTOS version of Linux) - but they didn't. In fact, none of the other OS makers (Apple, Samsung, Microsoft, Palm, Nokia, Firefox, Ubuntu, Jolla) used a RTOS version of their OS, even though they could have.

If using a RTOS was so important, and had such big advantages in mobile, why wouldn't any of these very smart people gone that way?

The answer is simply that the advantages of a RTOS simply aren't as important to a mobile OS (which is constrained by a limited battery life and limited processing power) as other things are, and so all of those companies built their OSs with mobile-first priorities.

Both iOS and Android can multitask just fine - but Apple and Google intentionally, after much thought and debate, designed in specific limitations in order to protect against undesired usage of battery and mobile data - they prevent things from running in the background unless it makes good sense not to. Android, being more open and customization by design, did this by making first-party apps have these limits, but allows the user to use third-party apps that don't (i.e., YouTube vs. third party YouTube clients), so that they won't be responsible for dead batteries and data overages from people who launch YouTube in the background and forget to turn it off.

The point is: Google could much more easily move Android to a LinuxRT base (instead of QNX) if they felt that RTOSs gave them an advantage - but they haven't, and they won't. Either way, they don't need or want QNX. If they did, Larry Page would have pulled out his Black Card in 2010 and bought the company - it would have cost less than one of several airplanes that Google owns. Or, maybe Apple would have bought it, or Microsoft...

Digging through troy post lol found one from a few about his post regards RTOS

[EFats]

If you find that can you post a link? I also think RT scheduling is a bad idea for phones. I've talked to people from Palm, Apple and Microsoft who all think BB was rather naive to think RT was a good idea in a modern phone. I'd love to read Troy's take on that subject.

If you think about it, RT makes perfect sense for other applications. It makes very little sense at all for this one.

Why? RT is not necessary for smartphone applications but that doesn't mean it is disadvantageous for a smartphone to run an RTOS.

You guys wanna start discussing OS issues, be prepared to do a lot of heavy reading. You might try starting here: https://developer.blackberry.com/nat...hitecture.html
before you roll on to other OS.

There is a good reason QNX is a microkernel design. There is also a good reason it is about the only commercially successful microkernel OS. (The disadvantage is not about being RT, it's the microkernel architecture which makes it a bit harder to wring performance out of it, but QNX was always designed for reliability and responsiveness, not outright speed)

Even before BB days, I tried to have a go with QNX. There's a reason why Linux, Android 'wins'. You can get it. QNX is not free nor available without effort and $$$. In comparison, anyone can grab Linux or Android. I managed to get a version of Linux booting on my embedded system and Android too. There was no way I could even trial QNX.

At the end of the day, users don't give a darn about OS design, they just want a 'free' phone that has apps.

As end user, I am much happier with the performance of my "old" BB 10 phones than I am with any new Android device. If I were the one making the call, I'd have done the same. Building OS from scratch is out of the question. Doing another Android port would've been stupid, it'd be a race to the bottom of the profit pit for hardware. Nothing wrong with using the OS you already own that is proven to work on more resource constrained systems than current smartphones

[Andy_bb_king]

Digging through troy post lol found one from a few about his post regards RTOS

So many ifs there is not good explanation to me.
But I do like the debate of this thread. Some are objective and some are subjective. But do not say your subjective opinions are objective facts.

Posted from my trusted Passport

[DrBoomBotz]

So many ifs there is not good explanation to me.
But I do like the debate of this thread. Some are objective and some are subjective. But do not say your subjective opinions are objective facts.

Posted from my trusted Passport

Everything is arbitrary until you know better.

[BlueTom316]

Go here if you are not sure what they are doing, or where QNX is deployed..
QNX in Automotive
When you click the URL, on the left side, it auto-starts you on automotive, but you can click through Industrial, Medical, Networking + Telecoms and Security + Defense.

[Jerry A]

No, no, you're talking about something totally different. Of course apps run in user processes. That's obvious and true for all OSes since forever basically.

I'm saying that an app shouldn't be tired to the lifecycle of a single process. Activities and services on Android aren't tied to a single long running process. The OS can start and stop underlying processes while an app's activities and services continue where they left off. This is why Android can run with less RAM and why you don't have the 8 open apps and we start killing apps behavior.

You can have 10 apps running on your android phone and, at any given time, fewer than 10 or even more than 10 processes running those apps. Android (and iOS and Windows) manage that much more elegantly than BB10 is able to. This is why apps suddenly disappear in BB10 and lose their state. It's also why BB10 can't even run properly with 1G of RAM.



I'm saying what is provided by Qt and Cascades is extremely primitive compared to what we have in iOS, and even compared to what we have in Android or Windows. Actually, it's really not even close when comparing iOS core graphics, core animation, uikit, spritekit, metal, etc to what BB10 offers. Qt was readily available and free, but that doesn't mean it was comparable to the start of the art in 2013. It was readily available and free.

But again, it's not just the graphics stuff, all the rest of the frameworks and APIs are similarly primitive in BB10 when compared with Windows, Android, and iOS.

Another way to look at it - it's not primitive, it's exactly what it's supposed to be - an embedded RTOS.

Maybe it wasn't the right fit. After all, this was an OS for VME boards, car consoles and microcontrollers.

It definitely needed more high-level interfaces to achieve a better end-user experience.

What I really would've loved to see is BB10 without the overhead of the Linux runtime. My gut tells things would've run a lot smoother.

[Jerry A]

So many ifs there is not good explanation to me.
But I do like the debate of this thread. Some are objective and some are subjective. But do not say your subjective opinions are objective facts.

Posted from my trusted Passport

Micro v. monolith kernel will always be subjective.

[app_Developer]

Another way to look at it - it's not primitive, it's exactly what it's supposed to be - an embedded RTOS.

Maybe it wasn't the right fit. After all, this was an OS for VME boards, car consoles and microcontrollers.

I think that's exactly right. A modern smartphone is very different from the typical QNX applications. I think QNX is excellent for other applications, but a poor fit for phones.

If BB10 had been built on Linux, I think they would have launched much earlier, they would have reduced the cost of adopting the latest hardware, and they could have had more compelling low/mid end devices. I don't know if all of that would have been enough to save BB10, but I think building on QNX did put them at a serious disadvantage.

[app_Developer]

Why? RT is not necessary for smartphone applications but that doesn't mean it is disadvantageous for a smartphone to run an RTOS.

Two reasons why RT is a disadvantage in modern phones. The first is that if you make strict timing guarantees to processes, then you severely limit your opportunity to coalesce work such that you maximize micro sleep time. This is a requirement for a modern smartphone with powerful processors and tiny batteries (and no cooling fans). RT introduces constraints that interfere with this requirement.

The second is that an RT strategy is inefficient when you have apps that may or may not (or should not) be attached to a process at any given time. Since phones can't swap dirty pages out to their really cheap/slow flash, it's important for the OS to be able to freely stop and start user processes without it being noticeable to the user. A scheduler has to take that into account. Again, introducing RT constraints to this problem make no sense since RT hardly buys you anything useful in this type of device.

[crackbrry fan]

Apple doesn't make an "Apple Infotainment system." They do make an app called Car Play that uses the car's existing digitizer and display to run apps remotely from an iPhone, but that has little to do with QNX, except that Car Play is an app that runs on a number of platforms, including Linux, Windows, and QNX For Cars.

But the only consumer "gadget" that uses QNX is a BB10 phone. Otherwise, QNX is mostly middleware for cars and control software for industrial uses - virtually no consumer-based applications for it to date.

Apple CarPlay Infotainment System Runs on BlackBerry�s QNX
Apple has announced their �iOS in a car� initiative dubbed CarPlay. Apple said today that Ferrari, Mercedes-Benz, and Volvo will unveil vehicles with the CarPlay infotainment system this week...

by Lucas Atkins March 3, 2014
Apple has announced their �iOS in a car� initiative dubbed CarPlay. Apple said today that Ferrari, Mercedes-Benz, and Volvo will unveil vehicles with the CarPlay infotainment system this week at the Geneva Auto Show.

Other auto manufacturers are lining up to include Apple CarPlay in future vehicles. Some of these auto manufacturers include*BMW, Ford, General Motors, Honda, Hyundai, Jaguar, Kia, Mitsubishi, Nissan, Peugeot Citro�n, Subaru, Suzuki and Toyota.

Apple�s CarPlay will require an iPhone for usage. The CarPlay system is primarily accessed by use of Siri, which will give you access to*notifications and voice command-driven calls and messaging, as well as iTunes, podcasts, third-party streaming services and so on.

�CarPlay has been designed from the ground up to provide drivers with an incredible experience using their iPhone in the car,� said Greg Joswiak, Apple�s vice president of iPhone and iOS Product Marketing. �iPhone users always want their content at their fingertips and CarPlay lets drivers use their iPhone in the car with minimized distraction. We have an amazing lineup of auto partners rolling out CarPlay, and we�re thrilled it will make its debut this week in Geneva.�

The CarPlay system would seem to be QNX CAR 2�s soon-to-be biggest rival in the infotainment system industry. Interestingly, the CarPlay system may actually run on top of QNX. You might have been aware that the QNX website lists Apple as a QNX strategic partner in automotive.

Yes, you read that correctly. Apple is a strategic partner for QNX in automotive. Could Apple be utilizing the power of QNX to operate the CarPlay infotainment system? We�ve reached out to BlackBerry and QNX to determine if CarPlay is using QNX and will update this post accordingly.

What implications do you think Apple�s CarPlay could have on the continued success of the QNX CAR 2 infotainment with auto manufacturers?

*UPDATE* � We reached out to Paul Leroux at QNX and he has confirmed our presumption:

�Connectivity to smartphones and other mobile devices is a key strength of QNX Software Systems� platform for car infotainment systems, and many automakers and tier one automotive suppliers use our platform to implement smartphone/head-unit integration in their vehicles. We have a long-standing partnership with Apple to ensure high-quality connectivity with their devices, and this partnership extends to support for Apple CarPlay.�

And I'm certain that you are wrong with respect to only BB10 really think the semantics needs to cease when one refers to "Apples Infotainment "

Courtesy QNX:

Over the past 35 years, QNX software has become a big part of everyday life. People encounter QNX-controlled systems whenever they drive, shop, watch TV, use the Internet, or even turn on a light. Its ultra-reliable nature means QNX software is the preferred choice for life-critical systems such as air traffic control systems, surgical equipment, and nuclear power plants. And its cool multimedia features have QNX software turning up in everything from in-dash radios and infotainment systems to the latest casino gaming terminals.

Global leaders like Cisco, Delphi, General Electric, Siemens, and Thales have discovered QNX Software Systems gives them the only software platform upon which to build reliable, scalable, and high-performance applications for markets such as telecommunications, automotive, medical instrumentation, automation, security, and more.


Posted via CB10

[Bluenoser63]

If you find that can you post a link? I also think RT scheduling is a bad idea for phones. I've talked to people from Palm, Apple and Microsoft who all think BB was rather naive to think RT was a good idea in a modern phone. I'd love to read Troy's take on that subject.

If you think about it, RT makes perfect sense for other applications. It makes very little sense at all for this one.

Course they would say that as they went in another direction. They are completely biased.

[Bluenoser63]

Two reasons why RT is a disadvantage in modern phones. The first is that if you make strict timing guarantees to processes, then you severely limit your opportunity to coalesce work such that you maximize micro sleep time. This is a requirement for a modern smartphone with powerful processors and tiny batteries (and no cooling fans). RT introduces constraints that interfere with this requirement.

The second is that an RT strategy is inefficient when you have apps that may or may not (or should not) be attached to a process at any given time. Since phones can't swap dirty pages out to their really cheap/slow flash, it's important for the OS to be able to freely stop and start user processes without it being noticeable to the user. A scheduler has to take that into account. Again, introducing RT constraints to this problem make no sense since RT hardly buys you anything useful in this type of device.

The first point makes no sense since BB10 has the same or better battery life than Android and iOS and Windows 10 Phone. Also there are more complaints about the Priv heating up than the other BB10 phones.

Actually the BB10 OS is great because of the RT strategy. It monitors the processes and if one freezes, it actually restarts the process on the lower levels (phone, networking, etc.) and on the higher level, it kills frozen apps. There is a reason that you never had to kill a frozen app, the RT kills those for you. You should know that as a developer and you have a bug in the app and it's frozen, the app is killed by the RT OS.

[app_Developer]

Course they would say that as they went in another direction. They are completely biased.

That's a very interesting assumption.

Why do you think they went in that direction to begin with? Actually, Microsoft didn't even start in that direction. They had an RT scheduler, which they then dropped as the realized it was a poor choice for their phones.

Biased by their experience building smartphones, perhaps. This is experience which the QNX team did not have.

[app_Developer]

The first point makes no sense since BB10 has the same or better battery life than Android and iOS and Windows 10 Phone. Also there are more complaints about the Priv heating up than the other BB10 phones.

I don't know that this is scientific. iOS and Android users tend to use more apps, and iPhones in particular have tiny batteries compared to like the Z30 or the Passport.

What I've seen in my experience is that iPhones have more consistent battery life (fewer wild swings) and tend to run cooler.

Actually the BB10 OS is great because of the RT strategy. It monitors the processes and if one freezes, it actually restarts the process on the lower levels (phone, networking, etc.) and on the higher level, it kills frozen apps. There is a reason that you never had to kill a frozen app, the RT kills those for you. You should know that as a developer and you have a bug in the app and it's frozen, the app is killed by the RT OS.

That is not what RT even means. It has nothing to do with that.

BTW, if you write an app that freezes on iOS or Android, it is also killed by the OS watchdog. But that has absolutely nothing to do with an RT scheduler.

[Jerry A]

I think that's exactly right. A modern smartphone is very different from the typical QNX applications. I think QNX is excellent for other applications, but a poor fit for phones.

If BB10 had been built on Linux, I think they would have launched much earlier, they would have reduced the cost of adopting the latest hardware, and they could have had more compelling low/mid end devices. I don't know if all of that would have been enough to save BB10, but I think building on QNX did put them at a serious disadvantage.

I think this is where you and I differ. My opinion is that most of their pain points were further up the stack.

Never got the impression that the abstraction layers or APIs were thought out or complete. Toss in the initial kitchen sink approach for languages and tools and you have a recipe for poor performance and lack of focus.

Remember the 10.0 Settings and Phone app both written in Air? And the inherent lag that came from being an Air app? Remember how we all danced for joy through the summer nites with the nymphs and sprites once 10.1 was released (said apps went native and dropped Air).

Given that lack of direction and focus, I'm not convinced building on top of Linux would've solved much.

[Dunt Dunt Dunt]

I wonder if they decided their was a need for an Android Runtime so early in development... why they didn't choose Linux?

No special QNX hardware drivers, no full runtime would have been required, many more developers out there with Linux experience.... Was it so hard to "secure" Linux back then? Or was it that BlackBerry didn't want their OS to be part of anything even close to "open"?

[Dunt Dunt Dunt]

So here's a question for some of the people on this forum who have a good understanding of QNX.

I have heard for a very long time, since RIM acquired QNX back in 2010, just how powerful, robust and amazing this company was.

It's been 6+ years since they have been part of the team and in that time frame have seen the full potential from them? I have seen lots of connected car concepts and I know they are part of 60 million cars on the road.

Outside of assisting with the Playbook, BB10 launches and some other products and services such as the tracking system for shipping containers etc, have we seen anything really large scale from that? Anything that's going to be a significant contributor to the bottom line?

I am not trying to sound like I am bad mouthing them or anything. I am trying to figure out if this is a lack of execution, lack of market awareness, lack of resources or something else. Been a shareholder for many years and I am patiently waiting on some growth on the software side that's going to turn this company around.

Thanks for any insight

Posted via CB10

BlackBerry paid $200 Million for QNX... that was 5 times revenues back then, which was much more than many taught it was worth.

QNX's revenues have grown over the years that have followed, but only in relation to what the company was and still is. Basically a small embedded software developer. While profitable, it has only a small market in comparison to what BlackBerry's other divisions once held... Software at this level doesn't get the attention or the revenue that selling $600 smartphones to the public get.

Wasn't a lack of anything really, just a lot of overselling on the part of some fans here and by BlackBerry in general. IoT and Driverless Cars... those are catch phrases that excite the imagination.... especially the imagination of investors.


The problem is BlackBerry's track record with acquired companies... QNX has lasted much longer than many. Dan Dodge leaving along with Chen's need for lower operating cost across the board but higher revenues, could kill what made small QNX the company it was. Potential is there...