Operating System Confusion!

QNX Newsgroups (Archives) qdn.public.qnxrtp.advocacy
1

Hi all,

Has anyone at QSSL noticed that there is still mass confusion over what
their OS products are and what their correct names are? There have been
numerous message over the past couple of weeks from people not knowing what
the difference is between QNX’s products. I read a message today from some
poor guy that was trying to start Fsys on QNX RTP!

Part of the problem is the newsgroups on inn.qnx.com. For example:

qdn.public.neutrino vs. qdn.public.qnxrtp.os → What’s the difference??
qdn.public.photon vs. qdn.public.qnxrtp.photon → Huh? Is one for QNX4?
comp.os.qnx → Which OS??

I do not understand why QSSL has not made an effort to separate the QNX4
info from the QNX RtP info. Is it some misguided attempt to make QNX4 users
feel like they are still a high priority? (spoken as a QNX4 user :wink:

Also, I think it would be nice if QSSL would try to define what the future
plans are for QNX4. What new features can be expected? Other than the
migration kit, are there any further plans to ease the migration to NTO?

To end on a positive note, I think that overall QSSL has done an excellent
job. The new OS and toys are very slick. I particularly like the
improvements in QNet over FLEET.

Regards,
Stephen

2

I agree. Parts are a bit confusing.
On the other hand as long as QSSL will send out a small, flexible and
robust OS we all can wait a bit for other extra things to be done …

stefan


Stephen Thomas wrote:

Hi all,

Has anyone at QSSL noticed that there is still mass confusion over what
their OS products are and what their correct names are? There have been
numerous message over the past couple of weeks from people not knowing what
the difference is between QNX’s products. I read a message today from some
poor guy that was trying to start Fsys on QNX RTP!

Part of the problem is the newsgroups on inn.qnx.com. For example:

qdn.public.neutrino vs. qdn.public.qnxrtp.os → What’s the difference??
qdn.public.photon vs. qdn.public.qnxrtp.photon → Huh? Is one for QNX4?
comp.os.qnx → Which OS??

I do not understand why QSSL has not made an effort to separate the QNX4
info from the QNX RtP info. Is it some misguided attempt to make QNX4 users
feel like they are still a high priority? (spoken as a QNX4 user > :wink:

Also, I think it would be nice if QSSL would try to define what the future
plans are for QNX4. What new features can be expected? Other than the
migration kit, are there any further plans to ease the migration to NTO?

To end on a positive note, I think that overall QSSL has done an excellent
job. The new OS and toys are very slick. I particularly like the
improvements in QNet over FLEET.

Regards,
Stephen

3

Hi Stephen,

yes … it’s a pity. The QSSL marketing is a complete disaster!

Neutrino 2.1 (aka QNX6) and the QNX Real-Time-Platform is very promising
from a technological point of view. The designers and developers did a
great job …

Armin


Also, I think it would be nice if QSSL would try to define what the future
plans are for QNX4.

They should implement QNET for QNX4 …


Stephen Thomas wrote:

Hi all,

Has anyone at QSSL noticed that there is still mass confusion over what
their OS products are and what their correct names are? There have been
numerous message over the past couple of weeks from people not knowing what
the difference is between QNX’s products. I read a message today from some
poor guy that was trying to start Fsys on QNX RTP!

Part of the problem is the newsgroups on inn.qnx.com. For example:

qdn.public.neutrino vs. qdn.public.qnxrtp.os → What’s the difference??
qdn.public.photon vs. qdn.public.qnxrtp.photon → Huh? Is one for QNX4?
comp.os.qnx → Which OS??

I do not understand why QSSL has not made an effort to separate the QNX4
info from the QNX RtP info. Is it some misguided attempt to make QNX4 users
feel like they are still a high priority? (spoken as a QNX4 user > :wink:

Also, I think it would be nice if QSSL would try to define what the future
plans are for QNX4. What new features can be expected? Other than the
migration kit, are there any further plans to ease the migration to NTO?

To end on a positive note, I think that overall QSSL has done an excellent
job. The new OS and toys are very slick. I particularly like the
improvements in QNet over FLEET.

Regards,
Stephen

4

I also like the new QRTP and Neutrino but seriously why would anyone call it
QNX 6. And why are is there a qdn.public.qnrtp.os and qdn.public.neutrino?
Maybe there should be a qnx.public.neutrino.advocacy just to keep things
consistant… I think though that its because the original neutrino 2.0 /
2.1 is not the same anymore as the QRTP. I know I have one machine setup
with Nto 2.1 installed with the latest patch but it is not QRTP. At least
the project is over, if I ever have to modify it again I’ll just install
QRTP. It would have been nice though if the old Nto and the new Nto on the
QRTP could have been kept consistant because its really difficult now to
know what works with what. I know there is no way I would trust my 2.1 app
to run on QRTP without retesting and making sure everything is still the
same, which I’m sure it isn’t.

Jon

Armin Steinhoff <A-Steinhoff"@web_.de> wrote in message
news:8rs1mo$snr$1@inn.qnx.com…

Hi Stephen,

yes … it’s a pity. The QSSL marketing is a complete disaster!

Neutrino 2.1 (aka QNX6) and the QNX Real-Time-Platform is very promising
from a technological point of view. The designers and developers did a
great job …

Armin


Also, I think it would be nice if QSSL would try to define what the
future
plans are for QNX4.

They should implement QNET for QNX4 …


Stephen Thomas wrote:

Hi all,

Has anyone at QSSL noticed that there is still mass confusion over what
their OS products are and what their correct names are? There have been
numerous message over the past couple of weeks from people not knowing
what
the difference is between QNX’s products. I read a message today from
some
poor guy that was trying to start Fsys on QNX RTP!

Part of the problem is the newsgroups on inn.qnx.com. For example:

qdn.public.neutrino vs. qdn.public.qnxrtp.os → What’s the
difference??
qdn.public.photon vs. qdn.public.qnxrtp.photon → Huh? Is one for QNX4?
comp.os.qnx → Which OS??

I do not understand why QSSL has not made an effort to separate the QNX4
info from the QNX RtP info. Is it some misguided attempt to make QNX4
users
feel like they are still a high priority? (spoken as a QNX4 user > :wink:

Also, I think it would be nice if QSSL would try to define what the
future
plans are for QNX4. What new features can be expected? Other than the
migration kit, are there any further plans to ease the migration to NTO?

To end on a positive note, I think that overall QSSL has done an
excellent
job. The new OS and toys are very slick. I particularly like the
improvements in QNet over FLEET.

Regards,
Stephen

5

Jonathan Richardson <jrichard@nospam.ise.bc.ca> wrote:

I also like the new QRTP and Neutrino but seriously why would anyone call it
QNX 6. And why are is there a qdn.public.qnrtp.os and qdn.public.neutrino?

we are in the middle of going to a new format
qdn.public.qnxrtp.*
and
qdn.public.qnx4.*

the .neutrino. groups will no longer exist

thanks for all of the feedback, we are listening :slight_smile:

Maybe there should be a qnx.public.neutrino.advocacy just to keep things
consistant… I think though that its because the original neutrino 2.0 /
2.1 is not the same anymore as the QRTP. I know I have one machine setup
with Nto 2.1 installed with the latest patch but it is not QRTP. At least
the project is over, if I ever have to modify it again I’ll just install
QRTP. It would have been nice though if the old Nto and the new Nto on the
QRTP could have been kept consistant because its really difficult now to
know what works with what. I know there is no way I would trust my 2.1 app
to run on QRTP without retesting and making sure everything is still the
same, which I’m sure it isn’t.

Try it, the QNX RTP’s kernel is the QNX Neutrino 2.1

Chris

Jon

Armin Steinhoff <A-Steinhoff"@web_.de> wrote in message
news:8rs1mo$snr$> 1@inn.qnx.com> …

Hi Stephen,

yes … it’s a pity. The QSSL marketing is a complete disaster!

Neutrino 2.1 (aka QNX6) and the QNX Real-Time-Platform is very promising
from a technological point of view. The designers and developers did a
great job …

Armin


Also, I think it would be nice if QSSL would try to define what the
future
plans are for QNX4.

They should implement QNET for QNX4 …


Stephen Thomas wrote:

Hi all,

Has anyone at QSSL noticed that there is still mass confusion over what
their OS products are and what their correct names are? There have been
numerous message over the past couple of weeks from people not knowing
what
the difference is between QNX’s products. I read a message today from
some
poor guy that was trying to start Fsys on QNX RTP!

Part of the problem is the newsgroups on inn.qnx.com. For example:

qdn.public.neutrino vs. qdn.public.qnxrtp.os → What’s the
difference??
qdn.public.photon vs. qdn.public.qnxrtp.photon → Huh? Is one for QNX4?
comp.os.qnx → Which OS??

I do not understand why QSSL has not made an effort to separate the QNX4
info from the QNX RtP info. Is it some misguided attempt to make QNX4
users
feel like they are still a high priority? (spoken as a QNX4 user > :wink:

Also, I think it would be nice if QSSL would try to define what the
future
plans are for QNX4. What new features can be expected? Other than the
migration kit, are there any further plans to ease the migration to NTO?

To end on a positive note, I think that overall QSSL has done an
excellent
job. The new OS and toys are very slick. I particularly like the
improvements in QNet over FLEET.

Regards,
Stephen

6

Jonathan Richardson <jrichard@nospam.ise.bc.ca> wrote:

I also like the new QRTP and Neutrino but seriously why would anyone call it
QNX 6. And why are is there a qdn.public.qnrtp.os and qdn.public.neutrino?

we have gone to a new format thanks to all of the excellent advice from the QNX
community…

qnx.public.qnxrtp.*
qnx.public.qnx4.*

The uname outputs are still being decided, so hang on for more…
thanks again,

Chris

Maybe there should be a qnx.public.neutrino.advocacy just to keep things
consistant… I think though that its because the original neutrino 2.0 /
2.1 is not the same anymore as the QRTP. I know I have one machine setup
with Nto 2.1 installed with the latest patch but it is not QRTP. At least
the project is over, if I ever have to modify it again I’ll just install
QRTP. It would have been nice though if the old Nto and the new Nto on the
QRTP could have been kept consistant because its really difficult now to
know what works with what. I know there is no way I would trust my 2.1 app
to run on QRTP without retesting and making sure everything is still the
same, which I’m sure it isn’t.

Jon

Armin Steinhoff <A-Steinhoff"@web_.de> wrote in message
news:8rs1mo$snr$> 1@inn.qnx.com> …

Hi Stephen,

yes … it’s a pity. The QSSL marketing is a complete disaster!

Neutrino 2.1 (aka QNX6) and the QNX Real-Time-Platform is very promising
from a technological point of view. The designers and developers did a
great job …

Armin


Also, I think it would be nice if QSSL would try to define what the
future
plans are for QNX4.

They should implement QNET for QNX4 …


Stephen Thomas wrote:

Hi all,

Has anyone at QSSL noticed that there is still mass confusion over what
their OS products are and what their correct names are? There have been
numerous message over the past couple of weeks from people not knowing
what
the difference is between QNX’s products. I read a message today from
some
poor guy that was trying to start Fsys on QNX RTP!

Part of the problem is the newsgroups on inn.qnx.com. For example:

qdn.public.neutrino vs. qdn.public.qnxrtp.os → What’s the
difference??
qdn.public.photon vs. qdn.public.qnxrtp.photon → Huh? Is one for QNX4?
comp.os.qnx → Which OS??

I do not understand why QSSL has not made an effort to separate the QNX4
info from the QNX RtP info. Is it some misguided attempt to make QNX4
users
feel like they are still a high priority? (spoken as a QNX4 user > :wink:

Also, I think it would be nice if QSSL would try to define what the
future
plans are for QNX4. What new features can be expected? Other than the
migration kit, are there any further plans to ease the migration to NTO?

To end on a positive note, I think that overall QSSL has done an
excellent
job. The new OS and toys are very slick. I particularly like the
improvements in QNet over FLEET.

Regards,
Stephen

7

Chris Travis <ctravis@qnx.com> wrote in message
news:8s2hhh$71n$1@nntp.qnx.com…

we are in the middle of going to a new format
qdn.public.qnxrtp.*
and
qdn.public.qnx4.*

the .neutrino. groups will no longer exist

thanks for all of the feedback, we are listening > :slight_smile:

Excellent!! We do appreciate it!
I bet all these Linux converts don’t know what to do with themselves.
Imagine, actually getting good support from an OS vendor :slight_smile:

8

Hi Chris,

Chris Travis wrote:

Jonathan Richardson <> jrichard@nospam.ise.bc.ca> > wrote:
I also like the new QRTP and Neutrino but seriously why would anyone call it
QNX 6. And why are is there a qdn.public.qnrtp.os and qdn.public.neutrino?

we are in the middle of going to a new format
qdn.public.qnxrtp.*
and
qdn.public.qnx4.*

It’s clear so far for the news groups … but what about the Neutrino
2.1 product line
for non-x86 CPU’s ?

Will the support for non-x86 CPU’s discontinued ??

Or are there plans to include the support of non-x86 CPU’s into QNX RTP
??

What happens in the meantime ??

BTW … are there plans to port QNET to QNX4 ??

Armin

9

Armin Steinhoff <A-Steinhoff@web_.de> wrote:

Hi Chris,

Chris Travis wrote:

Jonathan Richardson <> jrichard@nospam.ise.bc.ca> > wrote:
I also like the new QRTP and Neutrino but seriously why would anyone call it
QNX 6. And why are is there a qdn.public.qnrtp.os and qdn.public.neutrino?

we are in the middle of going to a new format
qdn.public.qnxrtp.*
and
qdn.public.qnx4.*

It’s clear so far for the news groups … but what about the Neutrino
2.1 product line
for non-x86 CPU’s ?

The problem is qdn.public.neutrino was causing confusion, but we do need
somewhere to discuss this, which we are looking into and should have a
solution later today… ie. a newsgroup for this… any suggestions what this
could be called?

Will the support for non-x86 CPU’s discontinued ??
Or are there plans to include the support of non-x86 CPU’s into QNX RTP
??

No, the support/product QNX Neutrino 2.1 still exists, eventually the QNX
realtime platform will have support for multi-platform targets.

What happens in the meantime ??

will let you know soon…

BTW … are there plans to port QNET to QNX4 ??

No, there are no plans at this time, the networking architecture is very
different, mainly, the concept of channels is not understood by QNX4.

Chris

Armin

10

Armin Steinhoff wrote:

Chris Travis wrote:

Armin Steinhoff <A-Steinhoff@web_.de> wrote:

Hi Chris,

Chris Travis wrote:

Jonathan Richardson <> jrichard@nospam.ise.bc.ca> > wrote:
I also like the new QRTP and Neutrino but seriously why would anyone call it
QNX 6. And why are is there a qdn.public.qnrtp.os and qdn.public.neutrino?

we are in the middle of going to a new format
qdn.public.qnxrtp.*
and
qdn.public.qnx4.*

It’s clear so far for the news groups … but what about the Neutrino
2.1 product line
for non-x86 CPU’s ?

The problem is qdn.public.neutrino was causing confusion, but we do need
somewhere to discuss this, which we are looking into and should have a
solution later today… ie. a newsgroup for this… any suggestions what this
could be called?

qdn.public.multi_target_nto ?

Could be qdn.public.qnxrtp.os.$CPU.
However, many issues will be CPU-irrelevant, so the current .os group
should be kept too.

  • igor
11

Chris Travis wrote:

Armin Steinhoff <A-Steinhoff@web_.de> wrote:

Hi Chris,

Chris Travis wrote:

Jonathan Richardson <> jrichard@nospam.ise.bc.ca> > wrote:
I also like the new QRTP and Neutrino but seriously why would anyone call it
QNX 6. And why are is there a qdn.public.qnrtp.os and qdn.public.neutrino?

we are in the middle of going to a new format
qdn.public.qnxrtp.*
and
qdn.public.qnx4.*

It’s clear so far for the news groups … but what about the Neutrino
2.1 product line
for non-x86 CPU’s ?

The problem is qdn.public.neutrino was causing confusion, but we do need
somewhere to discuss this, which we are looking into and should have a
solution later today… ie. a newsgroup for this… any suggestions what this
could be called?

qdn.public.multi_target_nto ?

Armin

12

Igor Kovalenko wrote:

Armin Steinhoff wrote:

Chris Travis wrote:

Armin Steinhoff <A-Steinhoff@web_.de> wrote:

Hi Chris,

Chris Travis wrote:

Jonathan Richardson <> jrichard@nospam.ise.bc.ca> > wrote:
I also like the new QRTP and Neutrino but seriously why would anyone call it
QNX 6. And why are is there a qdn.public.qnrtp.os and qdn.public.neutrino?

we are in the middle of going to a new format
qdn.public.qnxrtp.*
and
qdn.public.qnx4.*

It’s clear so far for the news groups … but what about the Neutrino
2.1 product line
for non-x86 CPU’s ?

The problem is qdn.public.neutrino was causing confusion, but we do need
somewhere to discuss this, which we are looking into and should have a
solution later today… ie. a newsgroup for this… any suggestions what this
could be called?

qdn.public.multi_target_nto ?


Could be qdn.public.qnxrtp.os.$CPU.
However, many issues will be CPU-irrelevant, so the current .os group
should be kept too.

… and every one will ask for support of PPC, MIPS, ARM and H4 CPUs
for the ‘qnxrtp.os’ :slight_smile: Too dangerous … IMHO.

Armin


  • igor
13

Chris Travis <ctravis@qnx.com> wrote:
: Armin Steinhoff <A-Steinhoff@web_.de> wrote:

:> Hi Chris,

:> Chris Travis wrote:
:>>
:>> Jonathan Richardson <jrichard@nospam.ise.bc.ca> wrote:
:>> > I also like the new QRTP and Neutrino but seriously why would anyone call it
:>> > QNX 6. And why are is there a qdn.public.qnrtp.os and qdn.public.neutrino?
:>>
:>> we are in the middle of going to a new format
:>> qdn.public.qnxrtp.*
:>> and
:>> qdn.public.qnx4.*

:> It’s clear so far for the news groups … but what about the Neutrino
:> 2.1 product line
:> for non-x86 CPU’s ?

: The problem is qdn.public.neutrino was causing confusion, but we do need
: somewhere to discuss this, which we are looking into and should have a
: solution later today… ie. a newsgroup for this… any suggestions what this
: could be called?

How about qdn.public.qnxrtp.kernel ?

-Ahmed

14

Previously, Martin Zimmerman wrote in qdn.public.qnxrtp.advocacy:

Previously, Chris Travis wrote in qdn.public.qnxrtp.advocacy:
we are in the middle of going to a new format
qdn.public.qnxrtp.*
and
qdn.public.qnx4.*

Foolish, you’re only promoting the confusion with that.

the .neutrino. groups will no longer exist

More foolishness, Neutrino IS the product/OS, QNXRTP is just a distribution of
Neutrino. Unless QSSL plans on obliterating any/all Neutrino product recognition,
this is a foolish choice.

Well, having ‘neutrino’ leads to confusion between ‘qnxrtp’ and
‘neutrino’ (are they the same?). Not having it obliterates ‘neutrino’
recognition. Go figure…

My reccomendation:

qdn.public.qnx2
qdn.public.qnx4
qdn.public.news
qdn.public.test
qdn.public.qnxrtp.installation
qdn.public.qnxrtp.newuser

qdn.public.qnx-jobs . . . . . . . . replaces . . . qdn.public.qnxjobs
qdn.public.qnx4.porting . . . . . . replaces . . . qdn.public.porting
qdn.public.neutrino.porting . . . . replaces . . . qdn.public.porting
qdn.public.qnx4.photon . . . . . . replaces . . . qdn.public.photon
qdn.public.neutrino . . . . . . . . replaces . . . qdn.public.qnxrtp.os
qdn.public.neutrino.apps . . . . . replaces . . . qdn.public.qnxrtp.applications
qdn.public.neutrino.devtools . . . replaces . . . qdn.public.qnxrtp.devtools
qdn.public.neutrino.photon . . . . replaces . . . qdn.public.qnxrtp.photon
qdn.public.qnx-advocacy . . . . . . replaces . . . qdn.public.qnxrtp.advocacy
qdn.public.qnxrtp.beta . . . . . . replaces . . . qdn.public.qnxrealtimeplatform.beta

That is just as confusing. ‘neutrino.apps’ vs ‘qnxrtp.applications’,
you think that’s easy?

thanks for all of the feedback, we are listening > :slight_smile:

Yes, but not well enough. QSSL is still sending the message that
QNXRtP is an OS, which is not correct. QDN also suggests that the OS’s
are QNX2, QNX4, NTO, and QNXRTP, very misleading, and very incorrect.

If that was my decision, I’d use ‘neutrino’ (or ‘nto’) prefix with ‘rtp’ and ‘oem’
suffixes. That would indicate that they share same core but have different packaging.
Group lists under them should also reflect what people usually do with respective
distribution. It would also be consistent with hardware packaging tradition
(OEM and Retail versions).

So, after qdn.public. we should have:

qnx4 - read only groups with 1 message explaining what is QNX4
… (I skip QNX4 groups for clarity)
neutrino - read only groups with 1 message explaining what is Neutrino
neutrino.core - common OS runtime
neutrino.photon - common Photon
neutrino.advocacy - flames and general interest issues.
neutrino.newbies - just crying for help

neutrino.oem - read-only group with 1 message explaining what is OEM Neutrino
neutrino.oem.setup - Setup and hardware support
neutrino.oem.crossdev - Cross development (may have subgroups for platforms)
neutrino.oem.embedding - Embedding (may have subgroups for architectures)
neutrino.oem.misc - Doesn’t fit well anywhere or concerns many
neutrino.oem.faq - FAQ

neutrino.rtp - read-only group with 1 message explaining what is RTP
neutrino.rtp.install - Setup and hardware compatibility
neutrino.rtp.apps - Applications
neutrino.rtp.devel - Self-hosted devel tools
neutrino.rtp.misc - Doesn’t fit well anywhere or concerns many
neutrino.rtp.faq - FAQ

All ‘explanatory’ groups should tell what the respective product is, who it is
targeted for, how it is different from other products/distributions and why one
should use this or that. Sort of mini-FAQ.

  • igor
15

Previously, Chris Travis wrote in qdn.public.qnxrtp.advocacy:

we are in the middle of going to a new format
qdn.public.qnxrtp.*
and
qdn.public.qnx4.*

Foolish, you’re only promoting the confusion with that.

the .neutrino. groups will no longer exist

More foolishness, Neutrino IS the product/OS, QNXRTP is just a distribution of
Neutrino. Unless QSSL plans on obliterating any/all Neutrino product recognition,
this is a foolish choice.

My reccomendation:

qdn.public.qnx2
qdn.public.qnx4
qdn.public.news
qdn.public.test
qdn.public.qnxrtp.installation
qdn.public.qnxrtp.newuser

qdn.public.qnx-jobs . . . . . . . . replaces . . . qdn.public.qnxjobs
qdn.public.qnx4.porting . . . . . . replaces . . . qdn.public.porting
qdn.public.neutrino.porting . . . . replaces . . . qdn.public.porting
qdn.public.qnx4.photon . . . . . . replaces . . . qdn.public.photon
qdn.public.neutrino . . . . . . . . replaces . . . qdn.public.qnxrtp.os
qdn.public.neutrino.apps . . . . . replaces . . . qdn.public.qnxrtp.applications
qdn.public.neutrino.devtools . . . replaces . . . qdn.public.qnxrtp.devtools
qdn.public.neutrino.photon . . . . replaces . . . qdn.public.qnxrtp.photon
qdn.public.qnx-advocacy . . . . . . replaces . . . qdn.public.qnxrtp.advocacy
qdn.public.qnxrtp.beta . . . . . . replaces . . . qdn.public.qnxrealtimeplatform.beta

thanks for all of the feedback, we are listening > :slight_smile:

Yes, but not well enough. QSSL is still sending the message that
QNXRtP is an OS, which is not correct. QDN also suggests that the OS’s
are QNX2, QNX4, NTO, and QNXRTP, very misleading, and very incorrect.

Cheers,
Camz.

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

16

Previously, Igor Kovalenko wrote in qdn.public.qnxrtp.advocacy:

Well, having ‘neutrino’ leads to confusion between ‘qnxrtp’ and
‘neutrino’ (are they the same?).

AFAIK, RTP is just a distribution of NTO. Just like Debian, Red Hat,
SuSe, etc are distributions of Linux.

That is just as confusing. ‘neutrino.apps’ vs ‘qnxrtp.applications’,
you think that’s easy?

I was only trying to associate the apps/applications with the OS, rather
than the distribution.

If that was my decision, I’d use ‘neutrino’ (or ‘nto’) prefix with ‘rtp’ and ‘oem’
suffixes. That would indicate that they share same core but have different packaging.

Good idea.

Group lists under them should also reflect what people usually do with respective
distribution. It would also be consistent with hardware packaging tradition
(OEM and Retail versions).

I agree.

neutrino - read only groups with 1 message explaining what is Neutrino
neutrino.core - common OS runtime
neutrino.photon - common Photon
neutrino.advocacy - flames and general interest issues.
neutrino.newbies - just crying for help

neutrino.oem - read-only group with 1 message explaining what is OEM Neutrino
neutrino.oem.setup - Setup and hardware support
neutrino.oem.crossdev - Cross development (may have subgroups for platforms)
neutrino.oem.embedding - Embedding (may have subgroups for architectures)
neutrino.oem.misc - Doesn’t fit well anywhere or concerns many
neutrino.oem.faq - FAQ

neutrino.rtp - read-only group with 1 message explaining what is RTP
neutrino.rtp.install - Setup and hardware compatibility
neutrino.rtp.apps - Applications
neutrino.rtp.devel - Self-hosted devel tools
neutrino.rtp.misc - Doesn’t fit well anywhere or concerns many
neutrino.rtp.faq - FAQ

This looks great, and fixes the confustion around NTO and the NTO
included in QXNRTP.

The only thing I’d change is the advocacy group to be independent from
QNX 2, 4, NTO-OEM, and NTO-RTP. We can rant about them all equally as well. :slight_smile:

What do you think Debbie?

Cheers,
Camz.

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

17

qnx4 - read only groups with 1 message explaining what is QNX4
… (I skip QNX4 groups for clarity)
neutrino - read only groups with 1 message explaining what is Neutrino
neutrino.core - common OS runtime
neutrino.photon - common Photon
neutrino.advocacy - flames and general interest issues.
neutrino.newbies - just crying for help

neutrino.oem - read-only group with 1 message explaining what is
OEM Neutrino
neutrino.oem.setup - Setup and hardware support
neutrino.oem.crossdev - Cross development (may have subgroups for
platforms)
neutrino.oem.embedding - Embedding (may have subgroups for architectures)
neutrino.oem.misc - Doesn’t fit well anywhere or concerns many
neutrino.oem.faq - FAQ

neutrino.rtp - read-only group with 1 message explaining what is
RTP
neutrino.rtp.install - Setup and hardware compatibility
neutrino.rtp.apps - Applications
neutrino.rtp.devel - Self-hosted devel tools
neutrino.rtp.misc - Doesn’t fit well anywhere or concerns many
neutrino.rtp.faq - FAQ

I like that!

  • igor
18

Previously, Chris Travis wrote in qdn.public.qnxrtp.advocacy:

BTW … are there plans to port QNET to QNX4 ??

No, there are no plans at this time, the networking architecture is very
different, mainly, the concept of channels is not understood by QNX4.

There is of course a potential low volume product category
here. Build a bridge using QNX4 and RTP admins that talk
over the network using raw packets.



Mitchell Schoenbrun --------- maschoen@pobox.com