Experiences with VxWorks compared to QNX

bridged with qdn.public.qnxrtp.advocacy
Rennie Allen

Re: Experiences with VxWorks compared to QNX

Post by Rennie Allen » Fri Feb 08, 2002 4:44 pm

Kris Warkentin wrote:
Ooh Ooh...I've got one. Here's a post install script for a package:

mount -Tio-net npm-qnet.so
cd /net
ls
sleep 5
rm -rf * &

That's more of a bomb than a virus but say goodbye to all the qnx hosts
running qnet on your network
More precisely that is a *nuclear* bomb :-)

Bill Caroselli

Re: Experiences with VxWorks compared to QNX

Post by Bill Caroselli » Fri Feb 08, 2002 5:01 pm

I used to laugh when the folks on CNN would say things like: "It's a good
thing the terrorists aren't doing (step 1), (step 2), (step 3), (etc.)". I
thought that some of these reporters should have been shot.

But, instead, we in the QNX community have you Kris! ;~}

--
Bill Caroselli -- 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net


"Kris Warkentin" <kewarken@qnx.com> wrote in message
news:a40umr$cbf$1@nntp.qnx.com...
Ooh Ooh...I've got one. Here's a post install script for a package:

mount -Tio-net npm-qnet.so
cd /net
ls
sleep 5
rm -rf * &

That's more of a bomb than a virus but say goodbye to all the qnx hosts
running qnet on your network

Kris Warkentin

Re: Experiences with VxWorks compared to QNX

Post by Kris Warkentin » Fri Feb 08, 2002 5:17 pm

What was it someone said? Scientists spend too much time thinking about
what they CAN do and not enough time thinking about what they SHOULD.

The sad thing is that neither I nor CNN reporters are NEARLY as imaginative
as terrorists and script k1dd13z. I spent two minutes thinking about it.
They think about it all the time. I was a sysadmin in university and
developed a (un?)healthy paranoia about security. Follow BugTraq
(http://www.securityfocus.com/) for a while and see if you don't.

cheers,

Kris

"Bill Caroselli" <qtps@earthlink.net> wrote in message
news:a40vum$riv$1@inn.qnx.com...
I used to laugh when the folks on CNN would say things like: "It's a good
thing the terrorists aren't doing (step 1), (step 2), (step 3), (etc.)".
I
thought that some of these reporters should have been shot.

But, instead, we in the QNX community have you Kris! ;~}

--
Bill Caroselli -- 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net


"Kris Warkentin" <kewarken@qnx.com> wrote in message
news:a40umr$cbf$1@nntp.qnx.com...
Ooh Ooh...I've got one. Here's a post install script for a package:

mount -Tio-net npm-qnet.so
cd /net
ls
sleep 5
rm -rf * &

That's more of a bomb than a virus but say goodbye to all the qnx hosts
running qnet on your network


Martin Zimmerman

Re: Experiences with VxWorks compared to QNX

Post by Martin Zimmerman » Sat Feb 09, 2002 6:58 am

Previously, Alec Saunders wrote in qdn.public.qnxrtp.advocacy:
Toolset. According to Wind River's May price list, your costs would be...
Allow me to make one little jab. Something that has annoyed every potential
QNX customer, current customer, and consultant since we were first able to
buy QNX commercially.

AT LEAST WINDRIVER PUBLISHES THEIR BASE/LIST PRICES.

Cheers,
Camz.

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

Alec Saunders

Re: Experiences with VxWorks compared to QNX

Post by Alec Saunders » Sat Feb 09, 2002 12:07 pm

Wind doesn't actually publish theirs, either Martin. But good point...
we're planning an overhaul of the web site in the near future, and I will
make sure we get the pricing info up there.

--
Alec Saunders (alecs@qnx.com)
VP Marketing, QNX Software Systems Limited

Bill Caroselli

Re: Experiences with VxWorks compared to QNX

Post by Bill Caroselli » Sat Feb 09, 2002 4:58 pm

"Martin Zimmerman" <camz@passageway.com> wrote in message
news:Voyager.020208235833.1935A@wooga.wooga.passageway.com...
Previously, Alec Saunders wrote in qdn.public.qnxrtp.advocacy:
Toolset. According to Wind River's May price list, your costs would
be...

Allow me to make one little jab. Something that has annoyed every
potential
QNX customer, current customer, and consultant since we were first able to
buy QNX commercially.

AT LEAST WINDRIVER PUBLISHES THEIR BASE/LIST PRICES.
True. And this is a big deal. You should also publish some discount
schedule.

As a consultant, I've had customers call for prices for quantity X and the
very next day someone else in a different industry will call for prices on
the same quantity X and get quoted different prices. And both quotes are
accompanied by "Shhh, don't tell anyone."

You have no idea how much that pisses people off.

--
Bill Caroselli -- 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net

Dmitri Poustovalov

Re: Experiences with VxWorks compared to QNX

Post by Dmitri Poustovalov » Sun Feb 10, 2002 2:34 am

What does affect QNX sales is lack of good tools and a strategy that would
resolve the problem. People buy tools. The most of people don't care about
OS architecture. But people believe that mighty tools will solve their
problems. Unfortunately at the time someone realizes that Tornado sucks it
is too late. And the reasonable 'what's the heck?' makes WRS knocking your
door with new tools offer. (Just for fun, take a look how many debuggers WRS
has).. A few times I got thru the process of OS selection for telco projects
(here, in NA). All the time one of the most important criteria was/is the
comprehensive tool chain. Not only editor/compiler/debugger story but also
availability of tools like Insight from Parasoft, for example. Perhaps
Insight is QNX-compatible but who knows this? Could QSSL compile a list of
QNX compatible 3rd-party tools those QNX customers would buy and use? Kind
of "QNX-compatible". Ask your big customers like Nortel and Motorola ;) and
small ones too, what tools they use. That will facilitate the process of OS
selection and establishing development environment for your customers.
Those were bad news. The good one is QNX rocks :)

"Alec Saunders" <alecs@qnx.com> wrote in message
news:a40rkh$a31$1@nntp.qnx.com...
"Kris Warkentin" <kewarken@qnx.com> wrote in message
news:a40ovo$7ou$1@nntp.qnx.com...
So, what you're saying is, we're selling too cheap ;-)

You point out two issues in your message, Kris. One is that you wonder
whether the price is right, and the other is you wonder whether pricing is
affecting our sales.

I think we're priced to hit the sweet spot in the market. Roughly 60% of
companies in the market have per developer budgets of $5,000 or more. If
we were to jack up our prices to Wind River levels, we would only be able
to
address 25% of the market. If we dropped our prices lower to the prices
that Microsoft charges for their products, we would add just 15 to 20% to
our total available market. So, yeah, not everyone can afford QNX, but
the
vast majority of the market can. And that's where I think we should be --
not only is QNX a great product technically, but it's also a great value
to
a purchaser.

To answer your second question, I don't believe that pricing is affecting
our sales, based on the info in the previous paragraph. Yes, there's
price
elasticity in our market place, but I think the issues of awareness are
much
much more detrimental to us than our pricing.

-----
Alec Saunders
VP Marketing, QNX Software

Robert Krten

Re: Experiences with VxWorks compared to QNX

Post by Robert Krten » Sun Feb 10, 2002 2:41 am

Dmitri Poustovalov <pdmitri@sympatico.ca> wrote:
What does affect QNX sales is lack of good tools and a strategy that would
resolve the problem. People buy tools. The most of people don't care about
OS architecture. But people believe that mighty tools will solve their
problems. Unfortunately at the time someone realizes that Tornado sucks it
is too late. And the reasonable 'what's the heck?' makes WRS knocking your
door with new tools offer. (Just for fun, take a look how many debuggers WRS
has).. A few times I got thru the process of OS selection for telco projects
(here, in NA). All the time one of the most important criteria was/is the
comprehensive tool chain. Not only editor/compiler/debugger story but also
availability of tools like Insight from Parasoft, for example. Perhaps
Insight is QNX-compatible but who knows this? Could QSSL compile a list of
QNX compatible 3rd-party tools those QNX customers would buy and use? Kind
of "QNX-compatible". Ask your big customers like Nortel and Motorola ;) and
small ones too, what tools they use. That will facilitate the process of OS
selection and establishing development environment for your customers.
Those were bad news. The good one is QNX rocks :)
Hi Dmitri,

it's sad that the "product" turned out by our universities and commercial
institutions doesn't realize that "vi" and "make" and the "printf debugger"
are just about all you need. I blame government cutbacks :-)

Cheers,
-RK
"Alec Saunders" <alecs@qnx.com> wrote in message
news:a40rkh$a31$1@nntp.qnx.com...
"Kris Warkentin" <kewarken@qnx.com> wrote in message
news:a40ovo$7ou$1@nntp.qnx.com...
So, what you're saying is, we're selling too cheap ;-)

You point out two issues in your message, Kris. One is that you wonder
whether the price is right, and the other is you wonder whether pricing is
affecting our sales.

I think we're priced to hit the sweet spot in the market. Roughly 60% of
companies in the market have per developer budgets of $5,000 or more. If
we were to jack up our prices to Wind River levels, we would only be able
to
address 25% of the market. If we dropped our prices lower to the prices
that Microsoft charges for their products, we would add just 15 to 20% to
our total available market. So, yeah, not everyone can afford QNX, but
the
vast majority of the market can. And that's where I think we should be --
not only is QNX a great product technically, but it's also a great value
to
a purchaser.

To answer your second question, I don't believe that pricing is affecting
our sales, based on the info in the previous paragraph. Yes, there's
price
elasticity in our market place, but I think the issues of awareness are
much
much more detrimental to us than our pricing.

-----
Alec Saunders
VP Marketing, QNX Software


--
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

Phil Olynyk

Re: Experiences with VxWorks compared to QNX

Post by Phil Olynyk » Sun Feb 10, 2002 8:09 pm

Robert Krten wrote:
Dmitri Poustovalov <pdmitri@sympatico.ca> wrote:
What does affect QNX sales is lack of good tools and a strategy that would
resolve the problem. People buy tools. The most of people don't care about
OS architecture. But people believe that mighty tools will solve their
problems. Unfortunately at the time someone realizes that Tornado sucks it
is too late. And the reasonable 'what's the heck?' makes WRS knocking your
door with new tools offer. (Just for fun, take a look how many debuggers WRS
has).. A few times I got thru the process of OS selection for telco projects
(here, in NA). All the time one of the most important criteria was/is the
comprehensive tool chain. Not only editor/compiler/debugger story but also
availability of tools like Insight from Parasoft, for example. Perhaps
Insight is QNX-compatible but who knows this? Could QSSL compile a list of
QNX compatible 3rd-party tools those QNX customers would buy and use? Kind
of "QNX-compatible". Ask your big customers like Nortel and Motorola ;) and
small ones too, what tools they use. That will facilitate the process of OS
selection and establishing development environment for your customers.
Those were bad news. The good one is QNX rocks :)

Hi Dmitri,

it's sad that the "product" turned out by our universities and commercial
institutions doesn't realize that "vi" and "make" and the "printf debugger"
are just about all you need. I blame government cutbacks :-)

Cheers,
-RK
As one of my colour-blind friends once said, "_I_ thought the shell was an
Integrated Development Environment!" Actually the colour is mostly a distraction
for him - but I see his point.

Phil Olynyk

"Alec Saunders" <alecs@qnx.com> wrote in message
news:a40rkh$a31$1@nntp.qnx.com...
"Kris Warkentin" <kewarken@qnx.com> wrote in message
news:a40ovo$7ou$1@nntp.qnx.com...
So, what you're saying is, we're selling too cheap ;-)

You point out two issues in your message, Kris. One is that you wonder
whether the price is right, and the other is you wonder whether pricing is
affecting our sales.

I think we're priced to hit the sweet spot in the market. Roughly 60% of
companies in the market have per developer budgets of $5,000 or more. If
we were to jack up our prices to Wind River levels, we would only be able
to
address 25% of the market. If we dropped our prices lower to the prices
that Microsoft charges for their products, we would add just 15 to 20% to
our total available market. So, yeah, not everyone can afford QNX, but
the
vast majority of the market can. And that's where I think we should be --
not only is QNX a great product technically, but it's also a great value
to
a purchaser.

To answer your second question, I don't believe that pricing is affecting
our sales, based on the info in the previous paragraph. Yes, there's
price
elasticity in our market place, but I think the issues of awareness are
much
much more detrimental to us than our pricing.

-----
Alec Saunders
VP Marketing, QNX Software



--
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

Bill Caroselli

Tool Chain

Post by Bill Caroselli » Sun Feb 10, 2002 8:57 pm

New thread time.

"Robert Krten" <nospam90@parse.com> wrote in message
news:a44mlj$h6f$1@inn.qnx.com...
it's sad that the "product" turned out by our universities and commercial
institutions doesn't realize that "vi" and "make" and the "printf
debugger"
are just about all you need. I blame government cutbacks :-)

What!
Don't get me wrong. I can work wonders with a few well placed printf()s.

When in a bind I often need to use a debugger to find out what led up to the
point where you are now executing that line that's commented:
// this should never happen

However,

I'm also a strong believe that software should debug itself. I have
developed many of my own software tools over the years that I can
incorporate into my software development projects. These features just lurk
quietly in the background using very little (but some) overhead. And then,
BANGZOOM! On that rare occasion (yeah right!) when a bug does raise it's
ugly head in my software I can just go back and look at the logs to see how
it got there.

I believe that (almost) as much time should go into the design of debugging
software as goes into the software itself.

--
Bill Caroselli -- 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net

Miguel Simon

Re: Experiences with VxWorks compared to QNX

Post by Miguel Simon » Sun Feb 10, 2002 9:08 pm

Hi Bill...

Bill Caroselli wrote:
I used to laugh when the folks on CNN would say things like: "It's a good
thing the terrorists aren't doing (step 1), (step 2), (step 3), (etc.)". I
thought that some of these reporters should have been shot.

But, instead, we in the QNX community have you Kris! ;~}
:))

I concur! :))

Miguel.

Miguel Simon

Re: Experiences with VxWorks compared to QNX

Post by Miguel Simon » Sun Feb 10, 2002 9:16 pm

Hi Chris...

QNX is much more 'gooder' as VxWorks is bad. :))

Just an honest biased opinion. :)

Cheers!

Miguel.

Chris Rose wrote:
I don't know if I will get an unbiased response, but here it goes anyway.

My company is hours away from signing a purchase request for QNX development
seats which we will use as the OS for our digital servo controller.
We just learned that another division of the company is using VxWorks and
they have extra licenses available (we think). They also have programmers
experienced with VxWorks. (My division has no one experienced with QNX). So
at the last moment we are re-evaluating our decision to use QNX.
We had originally ruled out Vx due to cost, and we thought the code may not
be as portable. (VxWorks AE though appears to be POSIX compliant)

My question is: Does anyone here have experience with both operating
systems? If so can you give me an unbiased opinion of both OS's?
--
---
my opinions are mine, only mine, solely mine, and they are not related
in any possible way to the institution(s) in which I study and work.
---
Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/
http://www.saic.com

Robert Krten

Re: Tool Chain

Post by Robert Krten » Sun Feb 10, 2002 9:21 pm

Bill Caroselli <qtps@earthlink.net> wrote:
New thread time.

"Robert Krten" <nospam90@parse.com> wrote in message
news:a44mlj$h6f$1@inn.qnx.com...

it's sad that the "product" turned out by our universities and commercial
institutions doesn't realize that "vi" and "make" and the "printf
debugger"
are just about all you need. I blame government cutbacks :-)

What!

Don't get me wrong. I can work wonders with a few well placed printf()s.

When in a bind I often need to use a debugger to find out what led up to the
point where you are now executing that line that's commented:
// this should never happen
That's about the only time I use a debugger as well -- the damn thing SIGSEGV'd
and now I need to know where. I turn on the debugger, it translates the magical
hex goop virtual address into a line number, and I *might* poke around with a
few variables to see if it's "obvious" why it died.

I guess my "bad experience" with debuggers was one guy who spent two days in a
debugger tracing through his program only to find that a half-hour spent with
the source would have found his problem.
However,

I'm also a strong believe that software should debug itself. I have
developed many of my own software tools over the years that I can
incorporate into my software development projects. These features just lurk
quietly in the background using very little (but some) overhead. And then,
BANGZOOM! On that rare occasion (yeah right!) when a bug does raise it's
ugly head in my software I can just go back and look at the logs to see how
it got there.
I'm a great believer in the "default: printf ("%s %d should never happen\n", __FILE__, __LINE__);"
statement.
I believe that (almost) as much time should go into the design of debugging
software as goes into the software itself.
That's the essence of "Software Quality Assurance" that *MOST* high tech companies
don't seem to grasp.

The attitude seems to be one of "Hey, cool! It compiled! Ship it!".

I worked at Canadian Marconi once on a radar. It was *very* instructive.
After the software was "complete" I had to write a test plan, to see how the
software measured up to the requirements document. Then I designed a hardware
test jig. Then the SQA person sat with me for two days and watched the software
being tested. *THEN* it was approved. After that point, I submitted it to their
configuration management group. The "proof" that it still worked was that I took
a stock IBM-PC, formatted the hard disk, installed the OS and compiler, and downloaded
the source from the CM system. Then I came up with a ROM image. *IF* the checksum
matched, then the product was deemed to be properly in the CM system.

Now, this may be a bit overboard, but there is a point -- how many times have you
been told by tech support for any number of products, "Oh, you got a SIGSEGV at
address <blah>? Huh, cool. Try the latest version." In an embedded product,
this is simply not acceptable as a level of service. They should be able to track
the version that you have to their CM system or equivalent, and find the line that
failed, and even rebuild a fixed version *from that branch* that fixes *only* that
one bug. *That's* how you prove that the fix worked. The old excuse of trying
the latest version only means that the bug is either fixed or masked by something
else...

</rant off> :-)

Cheers,
-RK

--
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

Dmitri Poustovalov

Re: Experiences with VxWorks compared to QNX

Post by Dmitri Poustovalov » Mon Feb 11, 2002 2:29 am

"Robert Krten" <nospam90@parse.com> wrote in message
news:a44mlj$h6f$1@inn.qnx.com...
Dmitri Poustovalov <pdmitri@sympatico.ca> wrote:
What does affect QNX sales is lack of good tools and a strategy that
would
resolve the problem. People buy tools. The most of people don't care
about
OS architecture. But people believe that mighty tools will solve their
problems. Unfortunately at the time someone realizes that Tornado sucks
it
is too late. And the reasonable 'what's the heck?' makes WRS knocking
your
door with new tools offer. (Just for fun, take a look how many debuggers
WRS
has).. A few times I got thru the process of OS selection for telco
projects
(here, in NA). All the time one of the most important criteria was/is
the
comprehensive tool chain. Not only editor/compiler/debugger story but
also
availability of tools like Insight from Parasoft, for example. Perhaps
Insight is QNX-compatible but who knows this? Could QSSL compile a list
of
QNX compatible 3rd-party tools those QNX customers would buy and use?
Kind
of "QNX-compatible". Ask your big customers like Nortel and Motorola ;)
and
small ones too, what tools they use. That will facilitate the process of
OS
selection and establishing development environment for your customers.
Those were bad news. The good one is QNX rocks :)

Hi Dmitri,

it's sad that the "product" turned out by our universities and commercial
institutions doesn't realize that "vi" and "make" and the "printf
debugger"
are just about all you need. I blame government cutbacks :-)
:) Just a quote from Communication Sytem Design Magazine I received last
week:
" ... There was a tremendous boom in XYZ for Dummies books over the last
decade.
Well, if you are a dummy then you shouldn't be trying to do engineering."

I'd add to this that s/w development is becoming an industry in all areas
and, maybe,
embedded application development is still the vi-ed and printf-ed art.
In big companies where 200-300 developers are dayly adding lines of code to
flat-memory
system; for them, Insight and Purify can save a lot of manny. For QNX
availabilty of 3rd tools
means industry recognition that much more trustfull then 100 partnership
announces...
Cheers,
-RK

"Alec Saunders" <alecs@qnx.com> wrote in message
news:a40rkh$a31$1@nntp.qnx.com...
"Kris Warkentin" <kewarken@qnx.com> wrote in message
news:a40ovo$7ou$1@nntp.qnx.com...
So, what you're saying is, we're selling too cheap ;-)

You point out two issues in your message, Kris. One is that you wonder
whether the price is right, and the other is you wonder whether pricing
is
affecting our sales.

I think we're priced to hit the sweet spot in the market. Roughly 60%
of
companies in the market have per developer budgets of $5,000 or more.
If
we were to jack up our prices to Wind River levels, we would only be
able
to
address 25% of the market. If we dropped our prices lower to the
prices
that Microsoft charges for their products, we would add just 15 to 20%
to
our total available market. So, yeah, not everyone can afford QNX, but
the
vast majority of the market can. And that's where I think we should
be --
not only is QNX a great product technically, but it's also a great
value
to
a purchaser.

To answer your second question, I don't believe that pricing is
affecting
our sales, based on the info in the previous paragraph. Yes, there's
price
elasticity in our market place, but I think the issues of awareness are
much
much more detrimental to us than our pricing.

-----
Alec Saunders
VP Marketing, QNX Software





--
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

Misha Nefedov

Re: Tool Chain

Post by Misha Nefedov » Mon Feb 11, 2002 2:49 pm

I agree with what you have said, but you skipped an important part of your
case. That is: The software your try to fix was/is written by you. Your
statement sounds rather like: "I'm working along!, because this way I don't
need to use a debugger".
By taking an average company with at least 10 software guys, we can say with
very high probability that there is no project that is taken care of by one
or two guys. And very often the people that wrote/re-wrote the initial code
are not in the company any more. What happens next ? YOU end up with fifteen
(at least I guess) thousand lines of code and again, as very often happens,
the code is not written in your style (for some known reason;-[). In this
case use of the printf() debugging style becomes a difficult task and time
is definitely not on your side.

Debuggers are tools, to use a tool we need knowledge and experience
(TIME!).
Debuggers change, and they are very useful. We, software guys, very often
tend to pre-judge things. If we had a bad experience with a beta tool, we
will maintain our opinion, so that it is negative (especially if we don't
need this tool).

Self-debugging is a good thing, but it needs programmers with experience and
"skill".
This also raises a few concerns:
- overall performance
- you need a file system for logging
- size ;-)

Don't get me wrong ;-) I am on your side!

-Misha.

"Bill Caroselli" <qtps@earthlink.net> wrote in message
news:a46mge$54$1@inn.qnx.com...
New thread time.

"Robert Krten" <nospam90@parse.com> wrote in message
news:a44mlj$h6f$1@inn.qnx.com...

it's sad that the "product" turned out by our universities and
commercial
institutions doesn't realize that "vi" and "make" and the "printf
debugger"
are just about all you need. I blame government cutbacks :-)

What!

Don't get me wrong. I can work wonders with a few well placed printf()s.

When in a bind I often need to use a debugger to find out what led up to
the
point where you are now executing that line that's commented:
// this should never happen

However,

I'm also a strong believe that software should debug itself. I have
developed many of my own software tools over the years that I can
incorporate into my software development projects. These features just
lurk
quietly in the background using very little (but some) overhead. And
then,
BANGZOOM! On that rare occasion (yeah right!) when a bug does raise it's
ugly head in my software I can just go back and look at the logs to see
how
it got there.

I believe that (almost) as much time should go into the design of
debugging
software as goes into the software itself.

--
Bill Caroselli -- 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net


Post Reply

Return to “qdn.public.qnxrtp.advocacy”