Wow, Mike produced copy worthy of a glossy brochure! There's something to be said for that. QNX Software Systems had nothing to do with writing the article, you know. If it sounds sappy or like marketingspeak to say "something wonderful is coming," then, sorry, it was just regular guys getting overenthusiastic. This article was never anywhere near a PR department.
You raise valid points that I'd like to respond to. This issue is important to me, as it will be for everyone who's been through the BeOS experience and now finds QNX offering what looks like the same situation all over again.
I think QNX RTP differs in some fundamental ways. First of all, QSSL *is* involved in a desktop effort for RTP, though indirectly. (The Phoenix Developer Consortium -- only a splash page so far) was set up to organize people who want to get involved with RTP as a desktop OS. QSSL staff are active in this organization and have been very responsive through the beta period. I can't speak with authority about the absence of desktop references on the QNX website. What I've been told is that QSSL is taking care of the underpinnings and working with the Phoenix Consortium to help extend RTP to the desktop. How this will pan out remains to be seen, of course, but the mechanism is there.
Secondly, QSSL has the advantage of being well-established in its market and can leverage this for the desktop implementation. Things like Real Player, Flash, and so on that Be has struggled to add to BeOS and are appearing only now are already part of RTP's feature set because of the OS's background in IAs, etc. This is the same arrangement Be had in mind, of course, but QSSL is just farther along.
Then there's the question of direction. Be moved away from BeOS to focus on information appliances. QSSL is already well-established in information appliances and embedded systems and is expanding to the desktop. At least superficially, it seems the vectors here look better for RTP, as far as the desktop is concerned. Admittedly, the prime reason for a desktop implementation for both companies is to have a development platform for their embedded systems, but, ever since QSSL was approached by Gateway to provide the kernel, etc. for a new Amiga OS, QSSL has been actively involved with developers, through Phoenix, to go beyond that.
Actually, then, there's more to the story of what QNX RtP is "intended for" than might first be apparent.
Slashdot Mirror
Wow, Mike produced copy worthy of a glossy brochure! There's something to be said for that. QNX Software Systems had nothing to do with writing the article, you know. If it sounds sappy or like marketingspeak to say "something wonderful is coming," then, sorry, it was just regular guys getting overenthusiastic. This article was never anywhere near a PR department.
You raise valid points that I'd like to respond to. This issue is important to me, as it will be for everyone who's been through the BeOS experience and now finds QNX offering what looks like the same situation all over again.
I think QNX RTP differs in some fundamental ways. First of all, QSSL *is* involved in a desktop effort for RTP, though indirectly. (The Phoenix Developer Consortium -- only a splash page so far) was set up to organize people who want to get involved with RTP as a desktop OS. QSSL staff are active in this organization and have been very responsive through the beta period. I can't speak with authority about the absence of desktop references on the QNX website. What I've been told is that QSSL is taking care of the underpinnings and working with the Phoenix Consortium to help extend RTP to the desktop. How this will pan out remains to be seen, of course, but the mechanism is there.
Secondly, QSSL has the advantage of being well-established in its market and can leverage this for the desktop implementation. Things like Real Player, Flash, and so on that Be has struggled to add to BeOS and are appearing only now are already part of RTP's feature set because of the OS's background in IAs, etc. This is the same arrangement Be had in mind, of course, but QSSL is just farther along.
Then there's the question of direction. Be moved away from BeOS to focus on information appliances. QSSL is already well-established in information appliances and embedded systems and is expanding to the desktop. At least superficially, it seems the vectors here look better for RTP, as far as the desktop is concerned. Admittedly, the prime reason for a desktop implementation for both companies is to have a development platform for their embedded systems, but, ever since QSSL was approached by Gateway to provide the kernel, etc. for a new Amiga OS, QSSL has been actively involved with developers, through Phoenix, to go beyond that.
Actually, then, there's more to the story of what QNX RtP is "intended for" than might first be apparent.