why haven;t the news services covered QNXRTP?

Steve Furr wrote:

For you uname freaks:

Ah, that must be me!

Solaris:

%uname
SunOS
%uname -a
SunOS solaris4 5.8 Generic i86pc i386 i86pc

  1. This is bad enough and why should you repeat someone’s mistakes?
  2. You did even worse, because SunOS4 and SunOS5 are reasonably
    compatible at source level, except for drivers maybe. But QNX and NTO
    are totally different at libc level, which makes them complete strangers
    to each other.
  3. They have ‘i386’ in uname output, you have only ‘x86’ and ‘x86pc’,
    which nobody knows.

And nobody has heartburn over that.

You don’t actually know if anyone had heartburn. Perhaps somebody did.
And even if nobody did, some people do have heartburn with QNX/NTO now
and I don’t see any reason for you to be so stubborn on the issue which
you (apparently) believe is unimportant. Why not make us happy, if
others don’t care?

  • igor

Previously, Debbie Kane wrote in qdn.public.qnxrtp.advocacy:

The name of the product is QNX Reatlime Platform (QNX RTP)
The OS in the QNX RTP is QNX Neutrino.
The GUI for the QNX RTP is Photon.

I think that QSSL has mad a mistake in the labeling and communcation of
what QNX RTP actually is. There is an analog from the Linux world that
explains it much, much better than all of this banter.

QNX RTP is a “Distribution based on QNX/NTO 2.1”

This is similiar to RedHat, SuSe, Debian, etc.

IMHO, QSSL would be far better off if it started to describe QNX RTP as
an NTO distribution “that contains NTO 2.1 and Photon 2.0 components”.
This is terminology that folks are familiar with.

I believe this is explained in the Welcome message when you first boot into
the QNX Realtime Platform, availalbe by clicking on the top right icon of
the Shelf.

People read that? I don’t think many people are seriously reading that,
if they were some (not much, the official QSSL explanations are still
not clear for anyone not familiar with QNX already) of this confusion
might not exist.

Cheers,
Camz.


Martin Zimmerman camz@passageway.com
Camz Software Enterprises www.passageway.com/camz/qnx/
QNX Programming & Consulting

“J. Scott Franko” wrote:

Armin@Steinhoff_.de wrote:

Hi Scott,

“J. Scott Franko” wrote:

If you do a uname -a on solaris it doesn’t return solaris, instead it returns SunOS
or SunOS 5.5. If you do it on QRTP it returns QNX not QRTP. It should return NTO,
but thats a different story.

Yes … that’s a different story which has nothing to do with marketing

But what I was pointing out was that QSSL is being like sun. They have this unix
like OS that is the core thing they sell, but want to repackage it as something
else, so they add things like a new gui and call it the “platform”, or the
“operating environment”.

I like ‘operating environment’ more … it’s much clearer.

Its all pakaging and marketing and targetting.

Yes … and it is VERY important for a bussiness success.

I agree, but that has nothing to do with helping a developer or manager understand the
jumble.



The only real difference is between QNX and NTO.

No … currently we have to differenciate between:
QNX4, NTO 2.1 and QRTP 2.0 (not to mention that Augusta stuff)

QNX4 is completely different from the NTO product line.
NTO 2.1 comes with Photon 1.14 …
QRTP 2.0 uses Photon 2.0.
That means a PhAB application of NTO 2.1 is incompatible
with a PhAB application of QRTP 2.0.
NTO 2.1 supports x86, MIPS, PPC, H4 a.s.o …
QRTP 2.0 supports x86.

In the moment I feel like sitting on three different chairs > :slight_smile:


I’m sure it feels crazy to be supporting all that! ;O)

But really, when all this beta stuff finishes up, are you really going to try to market
all these different combinations?

Yes … of course.

A really simplified message is that there are two
different RTOS’s, QNX and NTO, two different and incompatable version of the GUI, 1.x,
and 2.x, and targets for many machines available as build options in qcc -V (which may
only work for NTO).

Yes … it is clearly a fact that NTO and QNX4 are completely different
operating systems.
The usage of the prefix QNX doesn’t change this … it’s producing just
big confusions.

Is the only reason that QRTP only support x86 because the other targets were just not
packaged with it?

No … the introduction of the Dinkumware libs has a big impact on their
development efforts.
IMHO … the rest of NTO 2.1 isn’t yet ported …

Could one easily add target support in the future (at the QSSL level?
AT the developer level?)?

That’s kernel business → a QSSL task.

Will the GUI eventually settle out so that Photon 2.0 is
supported on QNX4, and NTO2? Will QRTP keep up with the current NTO?

Photon 2.0 use threads, so a port to QNX 4 is nearly impossible.
QRTP includes a version of NTO which is based on the Dinkumware libs …
I hope we will
have a single unique version of NTO if the rest of NTO 2.1 is ported to
the Dinkumware libs.

Right now I can see putting up with the craziness because you guys are in the beta phase
of trying to broaden your market. But when the dust settles, there should be the legacy
QNX, the more modern NTO, the most current version of Photon that runs on both, and the
targets (which may only work with NTO).

That would be nice …

[ clip …]

Regards

Armin

Armin@steinhoff_.de wrote:

Debbie Kane wrote:

The name of the product is QNX Realtme Platform (QNX RTP)

my understanding is that the core product of QSSL is a RTOS and not a
platform.


Ah … Pete, the confusion starts again when you visit qdn.qnx.com. Have
a look
to the search field of ‘Search Knowledge Base’ and the selection choices
‘Search by: QRTP QNX4 QNX Neutrino Tips & Tricks’ … is QRTP an
operationg
system like QNX4 and QNX Neutrino ?? Is QRTP the third OS line of QSSL
??

Well Debbie appears to be listening. It only took twenty posts to get
to the point… there is an oversight on our webpage.

I’m sure now that you’ve raised the issue, the web page will be changed
to read QNX RTP instead of QRTP.

pete@qnx.com wrote:

Armin@steinhoff_.de wrote:

Debbie Kane wrote:

The name of the product is QNX Realtme Platform (QNX RTP)

my understanding is that the core product of QSSL is a RTOS and not a
platform.

And you are correct. The platform consists of the core product, plus
a bunch of other stuff that is not part of the core product. The core
product in the platform is the Neutrino 2.1 RTOS, and one of the
major pieces of the `stuff’ is the Photon 2.0 GUI.

As far as the word platform goes, I much prefer it over operating environment.
Operating environment only implies that the computer will operate', whereas RTP also includes full development tools. Now you may still argue that platform’ doesn’t explain itself well enough, but I would argue that
operating environment does not adequately cover everything that’s in here.

Saying development environment doesn’t get you off the hook either, because
it might imply that RTP is not something for Joe User, and we hope that with
the help of some of our new friends, it will become that.

So it’s a platform. I we get to define what that actually means, so much the
better. As far as I know, there is nothing comparable out there to take the
cue from anyway.

Ah … Pete, the confusion starts again when you visit qdn.qnx.com. Have
a look
to the search field of ‘Search Knowledge Base’ and the selection choices
‘Search by: QRTP QNX4 QNX Neutrino Tips & Tricks’ … is QRTP an
operationg
system like QNX4 and QNX Neutrino ?? Is QRTP the third OS line of QSSL
??

Regards

Armin

Armin@Steinhoff_.de wrote:

No … the introduction of the Dinkumware libs has a big impact on their
development efforts.
IMHO … the rest of NTO 2.1 isn’t yet ported …

NTO2.1 (excluding Photon) is available in beta for PPC and MIPS. So it
has been ported. I’m sure they have Photon 2.0 running at PPC internally
too. May be some other platforms…

QRTP includes a version of NTO which is based on the Dinkumware libs …
I hope we will
have a single unique version of NTO if the rest of NTO 2.1 is ported to
the Dinkumware libs.

RTP does not use Dinkumware libs as of now. And they in fact have single
source tree for both RTP and OEM NTO. They simply do releases of both in
‘interleaved’ manner. I.e., the release OEM NTO, do some more
development, release RTP, do some more development, release OEM NTO, …

So when either of branches comes out it is normally latest greatest and
includes all relevant updates of previous release of another branch.
There are few exceptions in hardware support though, because they target
different markets.

  • igor

Igor Kovalenko wrote:

Armin@Steinhoff_.de wrote:

No … the introduction of the Dinkumware libs has a big impact on their
development efforts.
IMHO … the rest of NTO 2.1 isn’t yet ported …


NTO2.1 (excluding Photon) is available in beta for PPC and MIPS.

IMHO x86 is also supported → conference CD

So it
has been ported. I’m sure they have Photon 2.0 running at PPC internally
too. May be some other platforms…

QRTP includes a version of NTO which is based on the Dinkumware libs …
I hope we will
have a single unique version of NTO if the rest of NTO 2.1 is ported to
the Dinkumware libs.


RTP does not use Dinkumware libs as of now. And they in fact have single
source tree for both RTP and OEM NTO.

If this is so … why is Photon 2.0 not available for NTO 2.1-beta-3 ??

They simply do releases of both in
‘interleaved’ manner. I.e., the release OEM NTO, do some more
development, release RTP, do some more development, release OEM NTO, …

sounds good so far …

So when either of branches comes out it is normally latest greatest and
includes all relevant updates of previous release of another branch.
There are few exceptions in hardware support though, because they target
different markets.

Hm … different targets covered by the same CVS tree? How does it work?

Regards

Armin

Armin@Steinhoff_.de wrote:

Igor Kovalenko wrote:

Armin@Steinhoff_.de wrote:

No … the introduction of the Dinkumware libs has a big impact on their
development efforts.
IMHO … the rest of NTO 2.1 isn’t yet ported …


NTO2.1 (excluding Photon) is available in beta for PPC and MIPS.

IMHO x86 is also supported → conference CD

That’s obvious so I implied it :slight_smile:

So it
has been ported. I’m sure they have Photon 2.0 running at PPC internally
too. May be some other platforms…

QRTP includes a version of NTO which is based on the Dinkumware libs …
I hope we will
have a single unique version of NTO if the rest of NTO 2.1 is ported to
the Dinkumware libs.


RTP does not use Dinkumware libs as of now. And they in fact have single
source tree for both RTP and OEM NTO.

If this is so … why is Photon 2.0 not available for NTO 2.1-beta-3 ??

Because single source tree applies for OS runtime, not for Photon.

  • igor

Igor Kovalenko wrote:

Armin@Steinhoff_.de wrote:

Igor Kovalenko wrote:

Armin@Steinhoff_.de wrote:

No … the introduction of the Dinkumware libs has a big impact on their
development efforts.
IMHO … the rest of NTO 2.1 isn’t yet ported …

[ clip … ]

RTP does not use Dinkumware libs as of now. And they in fact have single
source tree for both RTP and OEM NTO.

If this is so … why is Photon 2.0 not available for NTO 2.1-beta-3 ??


Because single source tree applies for OS runtime, not for Photon.

If there is the same runtime … my question again:

‘… why is Photon 2.0 not available for NTO 2.1-beta-3?’

Armin

There might be many reasons. The OEM version targets different market
and they’d have different level of liability for quality. They probably
did not want to burden themselves with support for it, until Photon2 is
polished some more.

Nothing prevents you from running Photon2 on OEM NTO2.1 for x86 target.
It will be essentially the same thing as RTP, just with little bit dated
core. And you can’t demand support for it, legally speaking.

  • igor

Armin@Steinhoff_.de wrote:

If there is the same runtime … my question again:

‘… why is Photon 2.0 not available for NTO 2.1-beta-3?’

Armin

<pete@qnx.com> wrote in message news:8rkdhm$h08$1@inn.qnx.com

Armin@steinhoff_.de wrote:

Debbie Kane wrote:

The name of the product is QNX Realtme Platform (QNX RTP)

my understanding is that the core product of QSSL is a RTOS and not
a
platform.


Ah … Pete, the confusion starts again when you visit qdn.qnx.com. Have
a look
to the search field of ‘Search Knowledge Base’ and the selection choices
‘Search by: QRTP QNX4 QNX Neutrino Tips & Tricks’ … is QRTP an
operationg
system like QNX4 and QNX Neutrino ?? Is QRTP the third OS line of QSSL
??

Well Debbie appears to be listening. It only took twenty posts to get
to the point… there is an oversight on our webpage.

I’m sure now that you’ve raised the issue, the web page will be changed
to read QNX RTP instead of QRTP.

Yes, I am reading this…and yes, it was an oversight, and has been changed.
Actually, the whole QDN has been updated to help minimize the confusion. For
example, and references to QNX Neutrino as a separate product has been
removed.

We will also be updating the newsgroups to better reflect our product
families. ie. qdn.public.qnx4.* as well as qdn.public.qnxrtp.*
Again, references to QNX Neutrino as a product family will be removed…as
it is now part of the QNX RTP.

Debbie Kane wrote:

pete@qnx.com> > wrote in message news:8rkdhm$h08$> 1@inn.qnx.com> …
Armin@steinhoff_.de wrote:

Debbie Kane wrote:

The name of the product is QNX Realtme Platform (QNX RTP)

my understanding is that the core product of QSSL
is a RTOS and not a platform.

Ah … Pete, the confusion starts again when you visit qdn.qnx.com.
Have a look to the search field of ‘Search Knowledge Base’ and
the selection choices ‘Search by: QRTP QNX4 QNX Neutrino
Tips & Tricks’ … is QRTP an operating system like QNX4
and QNX Neutrino ?? Is QRTP the third OS line of QSSL ??

Well Debbie appears to be listening. It only took twenty posts
to get to the point… there is an oversight on our webpage.

I’m sure now that you’ve raised the issue, the web page will be
changed be changed to read QNX RTP instead of QRTP.


Yes, I am reading this…and yes, it was an oversight, and has been changed.
Actually, the whole QDN has been updated to help minimize the confusion. For
example, and references to QNX Neutrino as a separate product has been
removed.

We will also be updating the newsgroups to better reflect our product
families. ie. qdn.public.qnx4.* as well as qdn.public.qnxrtp.*
Again, references to QNX Neutrino as a product family will be removed…as
it is now part of the QNX RTP.

Debbie,

does it mean that the new RTOS for all platforms will be called “QNX
RTP” ???
What about guys who are working on non x86 platforms today??
Where have they to search??

Do you mention QNX Neutrino as a product family… for my uderstanding
it’s an RTOS

BTW, what QNX product (RTOS) have guys to buy when their platform is
e.g. MIPS or PowerPC??
Where to look for support for it on the QNX homepage??

Some more confusion now… :frowning:(

Jutta

Armin@steinhoff_.de wrote:


So when either of branches comes out it is normally latest greatest and
includes all relevant updates of previous release of another branch.
There are few exceptions in hardware support though, because they target
different markets.

Hm … different targets covered by the same CVS tree? How does it work?

Not many of our OEMS use any of the desktop graphics cards, and not
many developers live with STPC’s and Media GX’s on their desks.

A lot of the OEM graphics chips also require a lot of hand holding because
everyone hooks them up differently, and often they have no BIOS, so
it’s definitely very custom work.

So even though all those drivers are in the same CVS tree, we just don’t
ship a lot of them on the RTP CD.

From uk.altavista.com tech news:

enjoy :slight_smile:



The latest UK Tech News from ZDNet UK



Neutrino OS is Unix flavour of the month

Related links
Apple expo: Users get OS X, but fears remain
Unix forum adopts a Microsoft-friendly face
Amigans take heart, Linux is here…


QNX Neutrino was picked to power 3Com’s Audrey Net appliance. And alliances
with the likes of Palm and Cisco are widely rumoured
Embedded operating systems are designed to be hidden from users. So if you
haven’t heard of QNX Software Systems’s QNX Neutrino, you’re not alone.

But QNX could become almost a household name, if rumours about deals in the
pipeline pan out. Neutrino may end up powering devices ranging from Palm
PDAs to Cisco Systems routers at some point in the not-too-distant future.

QNX (pronounced Cue-nix, rhymes with Unix) makes the embedded microkernel
operating system that powers 3Com’s new Audrey Net appliance and
Netpliance’s iOpener. QNX also markets a “microGUI” windowing interface
called Photon, which 3Com also licensed for the Audrey device.

Outside of the consumer market, the QNX Neutrino operating system powers
many other systems, particularly in the industrial and medical-equipment
fields. The Ontario, Canada-based company was founded 20 years ago as a
real-time operating system vendor.

Other companies in the embedded OS space include Microsoft, with its Windows
CE Embedded and NT Embedded products – embedded Linux vendors, such as
Lineo; and traditional real-time OS vendors, including Wind River Systems
and Lynx Systems (now known as LynuxWorks).

Until five years ago, QNX was an X86 shop only. Since then, the company has
ported its operating system to PowerPC and MIPS. It is working on ARM and
StrongARM ports of Neutrino, and it could have a “fairly reasonable set” of
its technologies ported to ARM/StrongARM within six months, officials said.

“We made our OS multiplatform to be able to grab more market share in other
markets, especially in telecommunications and consumer electronics,”
explained Greg Bergsma, QNX vice president of North American operations.
Rumours are flying that QNX has set its sights on some big targets. As part
of its work for 3Com, QNX developed technology to allow Audrey to sync with
Palm devices. Some industry watchers have hinted that Palm may be interested
in licensing QNX Neutrino for its StrongARM-based systems once QNX completes
its port.

Bergsma said talk of Palm licensing Neutrino “is not crazy”, but no such
deal has been made. A spokeswoman for Palm did not respond for a request to
comment by publication time.

Because Neutrino is built from the ground up on standard POSIX application
programming interfaces, porting non-Neutrino-based software to Neutrino is
fairly straightforward, he said.

In theory, “the Palm OS could become just another layer on top of our OS,”
Bergsma said. “But right now, that’s just pie in the sky.”

Another possible win for Neutrino, this time on the router front, might be
announced in early 2001, Bergsma said.

In a deal signed two years ago, Cisco chose QNX as its preferred real-time
OS vendor as part of Cisco’s “ongoing efforts to increase the reliability
and availability of data-voice-video networks”. Since then, not much seems
to have materialised from the partnership.

But come next year, Bergsma said, QNX will have more to say about Cisco. He
declined to provide further details. “Other telcos are interested in our
technology, too,” he added, but cited nondisclosure agreements as to why he
could say nothing more.

A Cisco spokesperson did not respond to a request for comment prior to
publication.

What’s QNX got that has so many different kinds of companies interested?

“Our technologies have been out there for 20 years. We’ve gotten it so we
can fit a lot of functionality in a very small footprint,” said Bergsma. And
unlike Linux, which requires licensers to provide source-code changes back
to the community, QNX owns the rights to all of its POSIX APIs, so vendors
can make changes to differentiate their products without having to go public
with them.