followup to Igor's post in newuser

From qnx.public.qnxrt.newuser

“Igor Kovalenko” <kovalenko@home.com> wrote in message
news:a2pjkg$27o$1@inn.qnx.com

Okay, I held up for long enough, here it goes.

[cut]



I’ve heard X86 is actually at the end of list of supported platforms now,
in terms of revenues generated.

Given the track record of QNX to ditch a product line in favor of a new one,
it wouldn’t surprise me if they would drop x86 support…
(I mean it in a sarcastic way, but some part of me sees some truth in that)

Harris, you might wanna think how to improve this situation. There should
be
someone authorized to say something like ‘yes we know of a problem and
here
is what we’re doing about it’. Of course, when it is being the case. It
all
really comes down to the strategy QNX as a company uses to move forward.
So
far it is always has been strategy of hiding in the dark to make a fast
move
when opportunity comes. It is workable strategy for a small underdog and
it
got you this far, but if you ever want to become something more than that
in
public eyes, you’ve got to do some open moves. Defining some market
tendencies, instead of following ones. Some roadmaps would not hurt. Now I
am daydreaming > :wink:

That strikes a nerve. From where I sit, QNX has always work in
“fire extinquisher mode”. They seems to be going from reorganisation to
reorganisation;
running in circle, shutdown private distributor channels, setup their own
sales point,
then shutdown some of them down. While they keep on reorganising themselves
product development crawl.

They tell their sales peoplep to target industrial automation, then they
change
their mind and they target internet appliance, then they change their mind
and
target automotive then again a change for Telecom, etc. Each time, leaving
the people
they were able to attract, hanging. Today if I was to build a product that
needed some
sort of continuity, i’d think twice about using QNX6.

Product wise, things are going VERY VERY VERY slowly. 16 months after
the initial public release I still can’t get a list of installed IRQ handler
;-(((

The development tool story is a huge mess; CodeWarrior flop, then
you got all these unpolish kit all over the place Windows, Solaris,
self-hosted.
All not having quite the same feature set or version. Then there is now
Eclipse
in the pipe. When is something going to get finish with a professional
touch once
and for all. I just can get it into my head that in 2002. QNX is still
trying to define
their development tool.

Then their is the QNX4 situation, people having to switch ( supposely to
QNX6),
thus face decrease performance.

I’ll use another thread to talk about the good things :wink:

Mario “blowing off steam” Charest





  • igor

I’m in total agreement.
Previously, Mario Charest wrote in qdn.public.qnxrtp.advocacy:

From qnx.public.qnxrt.newuser

“Igor Kovalenko” <> kovalenko@home.com> > wrote in message
news:a2pjkg$27o$> 1@inn.qnx.com> …
Okay, I held up for long enough, here it goes.

[cut]

I’ve heard X86 is actually at the end of list of supported platforms now,
in terms of revenues generated.

Given the track record of QNX to ditch a product line in favor of a new one,
it wouldn’t surprise me if they would drop x86 support…
(I mean it in a sarcastic way, but some part of me sees some truth in that)

Harris, you might wanna think how to improve this situation. There should
be
someone authorized to say something like ‘yes we know of a problem and
here
is what we’re doing about it’. Of course, when it is being the case. It
all
really comes down to the strategy QNX as a company uses to move forward.
So
far it is always has been strategy of hiding in the dark to make a fast
move
when opportunity comes. It is workable strategy for a small underdog and
it
got you this far, but if you ever want to become something more than that
in
public eyes, you’ve got to do some open moves. Defining some market
tendencies, instead of following ones. Some roadmaps would not hurt. Now I
am daydreaming > :wink:

That strikes a nerve. From where I sit, QNX has always work in
“fire extinquisher mode”. They seems to be going from reorganisation to
reorganisation;
running in circle, shutdown private distributor channels, setup their own
sales point,
then shutdown some of them down. While they keep on reorganising themselves
product development crawl.

They tell their sales peoplep to target industrial automation, then they
change
their mind and they target internet appliance, then they change their mind
and
target automotive then again a change for Telecom, etc. Each time, leaving
the people
they were able to attract, hanging. Today if I was to build a product that
needed some
sort of continuity, i’d think twice about using QNX6.

Product wise, things are going VERY VERY VERY slowly. 16 months after
the initial public release I still can’t get a list of installed IRQ handler
;-(((

The development tool story is a huge mess; CodeWarrior flop, then
you got all these unpolish kit all over the place Windows, Solaris,
self-hosted.
All not having quite the same feature set or version. Then there is now
Eclipse
in the pipe. When is something going to get finish with a professional
touch once
and for all. I just can get it into my head that in 2002. QNX is still
trying to define
their development tool.

Then their is the QNX4 situation, people having to switch ( supposely to
QNX6),
thus face decrease performance.

I’ll use another thread to talk about the good things > :wink:

Mario “blowing off steam” Charest





\

  • igor
    \

To change the topic slightly, I often get the impression that QSSL views
customers as a nuisance that get in the way of them doing the cool stuff
they do. Since we’re only a small customer, I suppose we are just a
nuisance :slight_smile:. But it would be nice for QSSL to come out

It’s a very strange situation - tech people are generally very helpful and
friendly and ready to answer questions about almost anything. But getting
non-technical info is like pulling teeth. As an example - I check the QNX
website regularly, look at some of the newsgroups (eg qdn.public.news), get
the email update, and yet the first I know of the existance of 6.2 is via
slashdot.

Is it too much to ask that QSSL keep its customers updated with what’s
coming down the pipeline? Yes, I know there is probably some information
somewhere on the website or in a newsgroup somewhere, or available to those
with inside contacts, but it’s certainly not obviously apparent. I suppose
we could also sign up for some beta program, and find out that way, but we
have our own jobs to do… Why can’t QSSL trust its own customers with the
same info they distribute to the general public? Even the Evil Empire tells
people years in advance what the next version of the OS will be released,
what it will have in it, what will be fixed, what won’t. So what if everyone
laughs at them for not meeting their deadlines, changing the feature set
etc - at least you have an idea of what to expect. And at least they go out
of their way to help developers. How does QSSL expect us to plan for the
future in this kind of environment?

While I’m ranting, here’s some more. When we started our new development, we
weren’t sure whether we should switch from QNX4 to QNX 6 (this was in 2000).
We tried to get some advice from QSSL on the best approach to follow. We
wanted to know things like - how long would QNX4 be around, how stable was
RTP, when did they think it would ship, what features would the shipping
version have, could it do the things we wanted it to do, etc? I don’t think
these are unreasonable questions to ask of your vendor. The answer we got
was, decide for yourselves. And not delivered in a particular helpful way,
either.

In contrast, when we spoke to WindRiver, they sent 3 sales heavies the next
week to speak to us. Despite us telling them we weren’t likely to buy
because of tool price, history with QNX4 etc. While we still think QNX6 is
technically superior, and we’re not sorry with our decision to use it in our
new product, we’re feeling really nervous that QSSL sees us as some
bothersome step-children…

Finally, I’m glad someone mentioned the issue of development tools… I
don’t think my blood pressure could cope if I got onto that topic…

Phew. That feels better. Now, back to meeting those impossible deadlines…

Speaking for myself only, of course.
Marc

“Ian Cannon” <ianc@tecom.com.au> wrote in message
news:Voyager.020125085244.3300A@aresnode2.tecom.com.au

I’m in total agreement.
Previously, Mario Charest wrote in qdn.public.qnxrtp.advocacy:
From qnx.public.qnxrt.newuser

“Igor Kovalenko” <> kovalenko@home.com> > wrote in message
news:a2pjkg$27o$> 1@inn.qnx.com> …
Okay, I held up for long enough, here it goes.

[cut]

I’ve heard X86 is actually at the end of list of supported platforms
now,
in terms of revenues generated.

Given the track record of QNX to ditch a product line in favor of a new
one,
it wouldn’t surprise me if they would drop x86 support…
(I mean it in a sarcastic way, but some part of me sees some truth in
that)

Harris, you might wanna think how to improve this situation. There
should
be
someone authorized to say something like ‘yes we know of a problem and
here
is what we’re doing about it’. Of course, when it is being the case.
It
all
really comes down to the strategy QNX as a company uses to move
forward.
So
far it is always has been strategy of hiding in the dark to make a
fast
move
when opportunity comes. It is workable strategy for a small underdog
and
it
got you this far, but if you ever want to become something more than
that
in
public eyes, you’ve got to do some open moves. Defining some market
tendencies, instead of following ones. Some roadmaps would not hurt.
Now I
am daydreaming > :wink:

That strikes a nerve. From where I sit, QNX has always work in
“fire extinquisher mode”. They seems to be going from reorganisation to
reorganisation;
running in circle, shutdown private distributor channels, setup their
own
sales point,
then shutdown some of them down. While they keep on reorganising
themselves
product development crawl.

They tell their sales peoplep to target industrial automation, then
they
change
their mind and they target internet appliance, then they change their
mind
and
target automotive then again a change for Telecom, etc. Each time,
leaving
the people
they were able to attract, hanging. Today if I was to build a product
that
needed some
sort of continuity, i’d think twice about using QNX6.

Product wise, things are going VERY VERY VERY slowly. 16 months after
the initial public release I still can’t get a list of installed IRQ
handler
;-(((

The development tool story is a huge mess; CodeWarrior flop, then
you got all these unpolish kit all over the place Windows, Solaris,
self-hosted.
All not having quite the same feature set or version. Then there is now
Eclipse
in the pipe. When is something going to get finish with a professional
touch once
and for all. I just can get it into my head that in 2002. QNX is still
trying to define
their development tool.

Then their is the QNX4 situation, people having to switch ( supposely to
QNX6),
thus face decrease performance.

I’ll use another thread to talk about the good things > :wink:

Mario “blowing off steam” Charest





\

  • igor

    \

“Marc Rudolph” <mrudolph@nonospam.com> wrote in message
news:a2q41v$dg4$1@inn.qnx.com

To change the topic slightly, I often get the impression that QSSL views
customers as a nuisance that get in the way of them doing the cool stuff
they do. Since we’re only a small customer, I suppose we are just a
nuisance > :slight_smile:> . But it would be nice for QSSL to come out

It’s a very strange situation - tech people are generally very helpful and
friendly and ready to answer questions about almost anything. But getting
non-technical info is like pulling teeth. As an example - I check the QNX
website regularly, look at some of the newsgroups (eg qdn.public.news),
get
the email update, and yet the first I know of the existance of 6.2 is via
slashdot.

To QNX’s defense; 6.2 is a private beta. Anyone taking about it’s content
is in legal disagreement with the NDA they should have signed.

Is it too much to ask that QSSL keep its customers updated with what’s
coming down the pipeline?

Again to QNX’s defense, they have also been blame for saying some stuff up
front that didn’t turned into reality. They got some people pretty excited
over
CodeWarrior for QNX4, then they got some people real mad…

Yes, I know there is probably some information
somewhere on the website or in a newsgroup somewhere, or available to
those
with inside contacts, but it’s certainly not obviously apparent. I suppose
we could also sign up for some beta program, and find out that way, but we
have our own jobs to do… Why can’t QSSL trust its own customers with the
same info they distribute to the general public? Even the Evil Empire
tells
people years in advance what the next version of the OS will be released,
what it will have in it, what will be fixed, what won’t. So what if
everyone
laughs at them for not meeting their deadlines, changing the feature set
etc - at least you have an idea of what to expect. And at least they go
out
of their way to help developers. How does QSSL expect us to plan for the
future in this kind of environment?

I think they don’t have a real clue where they are going, so they can’t
really
tell us :wink: To some degree I think that’s normal, there are not as big
as Microsoft or VxWork, they can’t have their way and push people around.

That’s to be consider when making a chose to go the QNX way. Do not
make plans for the futur what so ever.

While I’m ranting, here’s some more. When we started our new development,
we
weren’t sure whether we should switch from QNX4 to QNX 6 (this was in
2000).
We tried to get some advice from QSSL on the best approach to follow. We
wanted to know things like - how long would QNX4 be around, how stable was
RTP, when did they think it would ship, what features would the shipping
version have, could it do the things we wanted it to do, etc? I don’t
think
these are unreasonable questions to ask of your vendor. The answer we got
was, decide for yourselves. And not delivered in a particular helpful way,
either.

Why would they care, what ever choice you make, you’d be buying from
them anyway… But I think more people will switch from QNX4 to a
different OS vendor then QSSL will ever admit (or realize)

In contrast, when we spoke to WindRiver, they sent 3 sales heavies the
next
week to speak to us. Despite us telling them we weren’t likely to buy
because of tool price, history with QNX4 etc. While we still think QNX6 is
technically superior, and we’re not sorry with our decision to use it in
our
new product, we’re feeling really nervous that QSSL sees us as some
bothersome step-children…

If you had choosen Wind-River, maybe you’d get the same kind of treatement
from them. Usually sales will bend over backward to get a sales, which QNX
didn’t had to do. Human nature I guess,

Finally, I’m glad someone mentioned the issue of development tools… I
don’t think my blood pressure could cope if I got onto that topic…

Phew. That feels better. Now, back to meeting those impossible
deadlines…

Speaking for myself only, of course.
Marc

“Mario Charest” <goto@nothingness.com> wrote in message
news:a2qduq$jlh$1@inn.qnx.com

To QNX’s defense; 6.2 is a private beta. Anyone taking about it’s content
is in legal disagreement with the NDA they should have signed.
Yes, I agree that I shouldn’t get any details when it’s in private beta.

(Well, it would be nice to at least get a vague roadmap, but nevermind).
The point is, they decided to make the info public (assuming OSNews didn’t
get their copy off the back of a truck…). But they don’t tell their
customers. Strange.

Again to QNX’s defense, they have also been blame for saying some stuff up
front that didn’t turned into reality. They got some people pretty
excited
over CodeWarrior for QNX4, then they got some people real mad…
Again, I agree in general. But, in this case, things are advanced enough

already for QNX to be prepared to let the general public see it. They must
have a list of new features and bug fixes. They must have a release date in
mind. (Before the end of summer, maybe? :slight_smile: Surely they could share some
info with us.

That’s to be consider when making a chose to go the QNX way. Do not
make plans for the futur what so ever.
:slight_smile: > . What does that say about people who need to make plans for the

future…

Why would they care, what ever choice you make, you’d be buying from
them anyway…
Well, there’s the point that it’s cheaper to keep your existing customers

than get new ones, so you would think it’s worth their while to care…

But I think more people will switch from QNX4 to a
different OS vendor then QSSL will ever admit (or realize)
I’m wondering if that’s not what they want - if you’re not IBM or Motorola

or Cisco, go somewhere else.

If you had choosen Wind-River, maybe you’d get the same kind of treatment
from them. Usually sales will bend over backward to get a sales, which
QNX
didn’t had to do. Human nature I guess,
Yes, I don’t have a rose tinted view of WindRiver. And for what they charge

for a developer seat, they can afford to spend some money on sales jaunts…
I guess I was at least impressed that WR took the view that sometimes (very
occasionally:) little companies turn into big companies, so it’s worth
putting in a little bit of effort.

Oh well, fortunately there’s work to be done, and deadlines to be met, so
I’ll go deal with the things that I do have some control over.

Marc
speaking for myself only, of course

Mario Charest wrote:

I think they don’t have a real clue where they are going, so they can’t
really
tell us > :wink: > To some degree I think that’s normal, there are not as big
as Microsoft or VxWork, they can’t have their way and push people around.

That’s to be consider when making a chose to go the QNX way. Do not
make plans for the futur what so ever.

No plans what-so-ever ? I can definately count on QNX6 having pthreads,
SMP, distributed networking, USB, a solid GUI with drag-and-drop, driver
support for a significant set of the hardware available on a x86
platform. I can count on the basic QNX6 architecture remaining intact
for the next 10 years or so (based on 2 decades of historical precedent).

Certainly there are things that can’t be planned for, but QSSL certainly
has a better record at delivering on things than M$ does. Did you jump
on-board with CE 1.0; how about CE 2.0, or perhaps CE 3.0. Did CE 1.0
allow you to actually accomplish anything ?

Do we as customers (or QSSL for that matter) know what vertical market
segments QNX6 will be a big winner in ? No. Does that mean the QSSL
can’t guarantee basic capabilities of the O/S ? No - they can and they do.

I think a valid statement is this:

“When considering QNX do not assume that your particular vertical will
continue to be the prime target for new development (by QSSL), even if
it is right now. Base the decision on fundamental features provided by
QNX (and that you can be sure will continue to exist for the time you
intend to base your product on QNX - this is a non-null set - not a
null set your statement infers), and accept that you may have to write
things that may be available OTS on other platforms. Only choose QNX if
this lack of OTS solutions is outweighed by the productivity benefits of
the QNX platform”.

One other piece of (general) advice… don’t let any emotion cloud
your judgement when making business decisions (much easier said than done).

“Rennie Allen” <rallen@csical.com> wrote in message
news:3C51A29D.8070106@csical.com

Mario Charest wrote:


I think they don’t have a real clue where they are going, so they can’t
really
tell us > :wink: > To some degree I think that’s normal, there are not as big
as Microsoft or VxWork, they can’t have their way and push people
around.

That’s to be consider when making a chose to go the QNX way. Do not
make plans for the futur what so ever.


No plans what-so-ever ? I can definately count on QNX6 having pthreads,
SMP

SMP has been flaky, and I wouldn’t be surprise if it gets dropped.

distributed networking,

USB,

Like USB in QNX4

a solid GUI with drag-and-drop,

Remember QNXWindows?

driver
support for a significant set of the hardware available on a x86
platform. I can count on the basic QNX6 architecture remaining intact
for the next 10 years or so (based on 2 decades of historical precedent).

Well not intact enough to required a sometime significat porting effort
QNX2<->QNX4, QNX4<-> QNX6.

Certainly there are things that can’t be planned for, but QSSL certainly
has a better record at delivering on things than M$ does.

I wasn’t making comparaison, nor does comparaison really matters to me.

Did you jump
on-board with CE 1.0; how about CE 2.0, or perhaps CE 3.0. Did CE 1.0
allow you to actually accomplish anything ?

Don’t know never tried them.

Do we as customers (or QSSL for that matter) know what vertical market
segments QNX6 will be a big winner in ? No. Does that mean the QSSL
can’t guarantee basic capabilities of the O/S ? No - they can and they
do.

I think a valid statement is this:

“When considering QNX do not assume that your particular vertical will
continue to be the prime target for new development (by QSSL), even if
it is right now. Base the decision on fundamental features provided by
QNX (and that you can be sure will continue to exist for the time you
intend to base your product on QNX - this is a non-null set - not a
null set your statement infers), and accept that you may have to write
things that may be available OTS on other platforms. Only choose QNX if
this lack of OTS solutions is outweighed by the productivity benefits of
the QNX platform”.


One other piece of (general) advice… don’t let any emotion cloud
your judgement when making business decisions (much easier said than
done).

Granted, I"m emotional (and hope to stay that way) and should have probably
tone down my statement.

Rennie Allen wrote:

Mario Charest wrote:

[ clip …]
I think a valid statement is this:

“When considering QNX do not assume that your particular vertical will
continue to be the prime target for new development (by QSSL), even if
it is right now. Base the decision on fundamental features provided by
QNX (and that you can be sure will continue to exist for the time you
intend to base your product on QNX - this is a non-null set - not a
null set your statement infers), and accept that you may have to write
things that may be available OTS on other platforms. Only choose QNX if
this lack of OTS solutions is outweighed by the productivity benefits of
the QNX platform”.

Could you name the ‘productivity benefits’ of QNX6 is we talk about
the development of application level software??

BTW … I wouldn’t talk so loudly about distributed networking and a
stable GUI, if you mean QNX6.

Armin

One other piece of (general) advice… don’t let any emotion cloud
your judgement when making business decisions (much easier said than done).

Ok, I’ll go back into my corner after this post…

“Rennie Allen” <rallen@csical.com> wrote in message
news:3C51A29D.8070106@csical.com

Certainly there are things that can’t be planned for, but QSSL certainly
has a better record at delivering on things than M$ does. Did you jump
on-board with CE 1.0; how about CE 2.0, or perhaps CE 3.0. Did CE 1.0
allow you to actually accomplish anything ?

Well, this could degenerate into a flame war, considering nto 1.0, nto 2.0,
rtp 6.0 etc. But that’s not the point. Your statement is true, but not very
helpful. I’m not a customer of M$ (at least not for embedded stuff). The
fact that their embedded offerings suck has no bearing on my reality. My
reality is that QSSL has been the vendor of choice, and I’m getting the
impression that QSSL isn’t interested in my needs, and would actually prefer
me to go away.

I don’t want to go away, because QNX 6 is very nice, it has lots of features
we like and need, it’s reliable, it works well, the support is reasonably
good etc. But I’m not emotional about it - there are things wrong too -
performance is not great, development tools are even worse, and most of all,
there is no information from QSSL that is ever going to get better, that
they have a plan, that they even care. Ok, so maybe I am emotional - too
many late nights recently :slight_smile:

The bottom line is, as much as we like QNX, and want to use it, we need some
business direction for the future. There comes a time when management wants
to see a business case for using some technology, not just a technical case.
If us techies have no info to provide a case, we will end up with a new
technology. That’s the unemotional bottom line.

Marc
speaking only for myself, of course.

Marc Rudolph wrote:


Well, this could degenerate into a flame war, considering nto 1.0, nto 2.0,
rtp 6.0 etc. But that’s not the point. Your statement is true, but not very
helpful. I’m not a customer of M$ (at least not for embedded stuff). The
fact that their embedded offerings suck has no bearing on my reality. My
reality is that QSSL has been the vendor of choice, and I’m getting the
impression that QSSL isn’t interested in my needs, and would actually prefer
me to go away.

Just for the record, my statement on CE was not meant to be inflamatory,
only to point out that “not knowing where one is going”, is endemic in
the industry, and affects even the most marketing oriented companies
(those who place high value on customer perception of company business
strategies, something that has not traditionally been a QSSL strength).


I don’t want to go away, because QNX 6 is very nice, it has lots of features
we like and need, it’s reliable, it works well, the support is reasonably
good etc. But I’m not emotional about it - there are things wrong too -
performance is not great, development tools are even worse, and most of all,
there is no information from QSSL that is ever going to get better, that
they have a plan, that they even care. Ok, so maybe I am emotional - too
many late nights recently > :slight_smile:

I can see your P.O.V… I think I am in a different boat, since I
wouldn’t have even considered seriously evaluating QNX6 as a basis for
a product until 6.1a (planning on sticking with QNX4 for the next 24
months). I am not exactly thrilled with a C++ compiler that doesn’t
handle a member space using declaration, but I am confident that this
will be rectified before it becomes a serious issue for me.

No plans what-so-ever ? I can definately count on QNX6 having pthreads,
SMP

SMP has been flaky, and I wouldn’t be surprise if it gets dropped.

It isn’t going anywhere. What have you found to be flaky? There was
an SMP bug in 6.1.0 that was quickly fixed with a package on
developers.qnx.com.

chris

\

Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

“Chris McKillop” <cdm@qnx.com> wrote in message
news:a2stk2$pco$1@nntp.qnx.com

No plans what-so-ever ? I can definately count on QNX6 having pthreads,
SMP

SMP has been flaky, and I wouldn’t be surprise if it gets dropped.


It isn’t going anywhere.

Is that an official statement, lol!

What have you found to be flaky?

In 6.1.0 it crashed a lot, in 6.1A phrealy would lock up.
(I got a version that fixed the problem)
In 6.2 beta, qnet the release not mention qnet doesn’t work.
Can’t think of nothing else for the moment

For every release (beta or official) there was always something
that work on non SMP but that broke on SMP.

It has never been has solid as the non-smp. Which is understandable
given the increase complexity, but that’s not excuse :wink:


an SMP bug in 6.1.0 that was quickly fixed with a package on
developers.qnx.com.


chris

\

Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

SMP has been flaky, and I wouldn’t be surprise if it gets dropped.


It isn’t going anywhere.

Is that an official statement, lol!

No - just one based on the customers who are using QNX’s SMP and find that
our SMP is a deciding factor in using QNX. So it is a personal observation
and is not an offical statement. :wink:


In 6.1.0 it crashed a lot, in 6.1A phrealy would lock up.
(I got a version that fixed the problem)
In 6.2 beta, qnet the release not mention qnet doesn’t work.
Can’t think of nothing else for the moment

For every release (beta or official) there was always something
that work on non SMP but that broke on SMP.

Ahhh…it isn’t SMP that is flaky then it is some APPS that are flaky
when running on an SMP machine. To me those are two very different
statements.

chris


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

You think users care what is it Chris? To them, both kernel and apps
(shipped along with kernel) are just ‘OS’. They come from same vendor,
users expect matched functionality. If kernel supports SMP but apps
(system apps) do not, that means for people ‘SMP is flaky’. QNX is still
the one to blame.

  • igor

Chris McKillop wrote:

SMP has been flaky, and I wouldn’t be surprise if it gets dropped.


It isn’t going anywhere.

Is that an official statement, lol!


No - just one based on the customers who are using QNX’s SMP and find that
our SMP is a deciding factor in using QNX. So it is a personal observation
and is not an offical statement. > :wink:


In 6.1.0 it crashed a lot, in 6.1A phrealy would lock up.
(I got a version that fixed the problem)
In 6.2 beta, qnet the release not mention qnet doesn’t work.
Can’t think of nothing else for the moment

For every release (beta or official) there was always something
that work on non SMP but that broke on SMP.


Ahhh…it isn’t SMP that is flaky then it is some APPS that are flaky
when running on an SMP machine. To me those are two very different
statements.

chris


Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

“Chris McKillop” <cdm@qnx.com> wrote in message
news:a30ilv$dea$1@nntp.qnx.com

I understand both your and Igor’s perspective that “a user” doesn’t
care if it is QNX’s SMP or an app that sucks on SMP. However, how far
do you take such a notion? If someone external to QNX does a driver that
doesn’t run reliably on an SMP system should QNX take the blame? To the
user it would seem that the SMP kernel causes the problems with the
driver,
not the other way around. Same can be said about multithreaded apps and
services in general. The fact is that your phrelay issue would probably

I was quite specific Chris. It can be taken as far as QSSL products go.
Everything shipped as a standard OS component is clearly your
responsibility. The phrelay surely is.

  • igor

“Chris McKillop” <cdm@qnx.com> wrote in message
news:a2tmb4$bk5$1@nntp.qnx.com

SMP has been flaky, and I wouldn’t be surprise if it gets dropped.


It isn’t going anywhere.

Is that an official statement, lol!


No - just one based on the customers who are using QNX’s SMP and find that
our SMP is a deciding factor in using QNX. So it is a personal
observation
and is not an offical statement. > :wink:

I understand making such a statement gives a negative perspective on the
situation.
Indeed it’s not all negative. I recommand to friends to buy SMP machine, so
they
can play around with SMP and gain some experience with this. It’s a great
technology. Of course I would feel extremely bad if those people would have
bought these things for nothing…


For every release (beta or official) there was always something
that work on non SMP but that broke on SMP.


Ahhh…it isn’t SMP that is flaky then it is some APPS that are flaky
when running on an SMP machine. To me those are two very different
statements.

Maybe for you Chris since you have an inside view of the problem,
but for me as a user/developer there is no difference. I have not
yet had a smooth experience running QNX6 on an SMP machine.
Doesn’t mean it’s unusable, in fact it’s great, but in ain’t smooth.


chris


Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

Mister McKillop.


Biting the hand that feeds you !! Wow !!

I guest if you can bitch back, it is probably because you have years of
fields experiences developping for pharmaceutical industry, power
plants, production lines, telecommunication devices, SCADA systems and
DCS systems of all types and more … So what ever any of these guys
have to says you already know. If you don’t have the field backgound,
remember that these guys do ! What is acceptable for one client may not
be for an other !

Ahhh…it isn’t SMP that is flaky then it is some APPS that are flaky
when running on an SMP machine. To me those are two very different
statements.

Maybe for you Chris since you have an inside view of the problem,
but for me as a user/developer there is no difference. I have not
yet had a smooth experience running QNX6 on an SMP machine.
Doesn’t mean it’s unusable, in fact it’s great, but in ain’t smooth.

I understand both your and Igor’s perspective that “a user” doesn’t
care if it is QNX’s SMP or an app that sucks on SMP. However, how far
do you take such a notion? If someone external to QNX does a driver that
doesn’t run reliably on an SMP system should QNX take the blame? To the
user it would seem that the SMP kernel causes the problems with the driver,
not the other way around. Same can be said about multithreaded apps and
services in general. The fact is that your phrelay issue would probably
happen on an non-SMP kernel as well, just harder to get the problem to
surface. It’s a bug and I am sure you have reported it (right?).


FYI - when I make a reply to a posting from you (Mario) or Igor I expect
there to be a different level of conversation going on. I would expect
a newbie or someone with less QNX (or OS experience in general) to lump
everything into a single “blob” and point a finger calling everything
“flaky”. However, when either of you (or any of the many other experienced
people that post here) do so it is “flame bait” and I am gonna call you
on it. :wink:


chris

\

Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

Biting the hand that feeds you !! Wow !!

I didn’t think I was doing that all.

I guest if you can bitch back, it is probably because you have years of
fields experiences developping for pharmaceutical industry, power
plants, production lines, telecommunication devices, SCADA systems and
DCS systems of all types and more … So what ever any of these guys
have to says you already know. If you don’t have the field backgound,
remember that these guys do ! What is acceptable for one client may not
be for an other !

I am not sure I follow. Just so I am clear, what did I say that made you
think I was being harsh to any of the guys posting on this thread/forum?
The worst I think i did was take a blanketing and generalized statement
and try to get a little more detail.

And, just for the record, I was a QNX customer/user/developer for nearly
5 years before I came to work for QNX. From autonomous robotic vehicles to
embedded sensor systems for mining research to high-speed vision systems
for industrial control and manufacturing (hi wayne!).

chris


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

“Chris McKillop” <cdm@qnx.com> wrote in message
news:a30ilv$dea$1@nntp.qnx.com

Ahhh…it isn’t SMP that is flaky then it is some APPS that are flaky
when running on an SMP machine. To me those are two very different
statements.

Maybe for you Chris since you have an inside view of the problem,
but for me as a user/developer there is no difference. I have not
yet had a smooth experience running QNX6 on an SMP machine.
Doesn’t mean it’s unusable, in fact it’s great, but in ain’t smooth.


I understand both your and Igor’s perspective that “a user” doesn’t
care if it is QNX’s SMP or an app that sucks on SMP. However, how far
do you take such a notion? If someone external to QNX does a driver that
doesn’t run reliably on an SMP system should QNX take the blame? To the
user it would seem that the SMP kernel causes the problems with the
driver,
not the other way around. Same can be said about multithreaded apps and
services in general.

The fact is that your phrelay issue would probably
happen on an non-SMP kernel as well, just harder to get the problem to
surface.

Quite true,

It’s a bug and I am sure you have reported it (right?).

Yes, and it was fixed in very little time

FYI - when I make a reply to a posting from you (Mario) or Igor I expect
there to be a different level of conversation going on. I would expect
a newbie or someone with less QNX (or OS experience in general) to lump
everything into a single “blob” and point a finger calling everything
“flaky”.

However, when either of you (or any of the many other experienced
people that post here) do so it is “flame bait” and I am gonna call you
on it. > :wink:

Fair enough. In fact I really hope you (or anyone else) do call on it
One can’t always present a fair or precise view of a situation
In a public forum like this, one person’s point of view SHOULD NEVER
be taken as the only mean of forming an opinion

One thing important to mention, some people may think I “know” stuff.
Well yes I know some stuff, but the stuff I’m told about I’m expected
to keep it to myself and that’s what I do. When I make comments
or speculate on what could happen, it’s all based on my own
evaluation of public facts.

I probably should have said that some (in fact just a few) componenents
of the OS are not all SMP friendly. But that doesn’t change the fact that
as a product QNX6

chris

\

Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/