Considering QNX - any feedback versus other RTOSes?

[Joseph_A_Dziedzic]

I’m considering QNX for a future project that my company will be developing.
I’m curious about opinions about QNX in general and QNX when compared to other
RTOSes (VxWorks, OSE, OS-9, Nucleus, LynxOS). For those of you who have
developed commercial-scale products using QNX, what were your opinions of QNX
after having completed a project? Would you use it again? What about QNET?
Was it as useful for peer-to-peer communications as it appears to be from the
glossy marketing stuff?

I’d appreciate any feedback - positive and negative - that anyone would care
to provide. Replies to this post would be welcome - if you’d prefer to send
e-mail, that would be fine too.

Thanks,
Joseph Dziedzic
Adaptec NTC

[Pete_DiMarco1]

We’re currently developing a product (an industrial controller) based on QNX. It’s the type of system that’s expected to be very reliable, but not exactly realtime. At a previous job we used OS-9 (version 3.0, circa 1993-4) for a very similar product.

A year and a half ago we did an evaluation of available OSes. I looked into VxWorks, pSOS, QNX, VRTX, Nucleus, and embedded Linux (but not OS-9; see below). Our requirements: x86 support, available GUI library, full MMU support, flash file system, reasonable footprint. OSE was only available for PPC and 68k, so it was out. I didn’t feel Linux was ready for embedded apps at that time, so it was out. VRTX was dead.

It eventually came down to VxWorks & QNX. Tough competition, or so we thought. We decided on VxWorks (they were the biggest, they were local, etc.). At the 1st day of training we found out that the VxWorks “kernel” is actually a primitive executive. What they call tasks are really threads. Memory protection required the programmer to specify protected regions by hand; everything lives in one big happy address space. Your application is a bunch of functions compiled in with their executive - you don’t even get to write your own “main()”. Anyway, we cancelled the PO during our lunch break.

QNX is much more to our liking. It’s basically a POSIX system without a swap file and with deterministic scheduling. Photon (the GUI) is pretty cool too, although it’s probably overkill for a lot of (small) applications.

To be fair to VxWorks, it’s been ported to nearly everything, including microcontrollers that lack an MMU. It’s also very compact. QNX 4 only runs on x86.

As far as OS-9 goes, I didn’t consider them because we had some problems with it: compiler bugs, a driver bug, a few kernel bugs… OS-9 does have some neat features - it’s POSIX-like, but differs in some ways that I think are better than POSIX. It’s a great OS compared to anything Microsoft makes, but I got burned once too many times.

Hope that helps.

• PDM

Previously, Joseph A. Dziedzic wrote in comp.os.qnx:

I’m considering QNX for a future project that my company will be developing.
I’m curious about opinions about QNX in general and QNX when compared to other
RTOSes (VxWorks, OSE, OS-9, Nucleus, LynxOS). For those of you who have
developed commercial-scale products using QNX, what were your opinions of QNX
after having completed a project? Would you use it again? What about QNET?
Was it as useful for peer-to-peer communications as it appears to be from the
glossy marketing stuff?

I’d appreciate any feedback - positive and negative - that anyone would care
to provide. Replies to this post would be welcome - if you’d prefer to send
e-mail, that would be fine too.

Thanks,
Joseph Dziedzic
Adaptec NTC

[Warren_Peece1]

I’ve been using QNX for a long, long time (started with QNX2 back in the
80’s) and I can’t say enough great things about it to do any justice. First
off, if you take a look at it from the standpoint of someone who has been
doing development on “traditional” systems for any length of time, it’s
extremely easy to overlook or undervalue some of QNX’s strongest attributes.
Speaking specifically of QNX6 (Neutrino, RtP, whatever you like to call it)
since you mentioned QNET, on the outside it appears a lot like your standard
“Un*x-like” O.S. due to the GNU tool set, availability of X, and so on.
Indeed you can use your standard approach to developing monolithic
applications if you should so choose, and the O.S. will perform wonderfully-
arguably as good or better depending of course on specific circumstances
than anything else out there today. It’s not until you’ve grown accustomed
to the extreme flexibility, reliability and modularity that embracing the
message-passing philosophy in the initial concepts of your designs that
you’ll realize exactly what you’ve found. By breaking extremely complex
applications down into a group of cooperating processes utilizing IPC for
coordination, you can isolate specific functionality into small modules with
a well defined interface. If the functionality requirements change, you can
address the changes in the affected module(s), and leave the remainder of
the system unaltered. If you experience problems in a module that cause it
to fail for some reason, the remaining modules will continue to run and you
can make provisions for them to detect the loss of the faulty module and
take corrective action if you should so desire. Perhaps in a given
implementation expansion is a consideration which may be addressed by simply
invoking multiple instances of certain modules, and if overall system
throughput becomes important you can distribute various modules across
multiple machines interconnected with QNET. While I won’t go so far as to
say there’s no difference between writing a multiple process application
designed to run on a single node vs. across QNET, the considerations are
minor enough to allow you to expand or contract to as many or as few
processing nodes as required without having to make any drastic changes.
While it’s certainly true that you can accomplish the same sort of thing
with other O.S.'s, it will remain a foreign sort of environment while in QNX
it’s merely a natural extension of the O.S. itsself. In fact, I dread the
thought of having to develop under traditional architecture systems because
I’ve become accustomed to the power and flexibility of the QNX resource
manager implementation and message passing methodology.

Heading down into the embedded realm, the QNX architecture again can look as
much like a “standard” O.S. as you like. If you dig a little deeper
however, you start to discover some very powerful features. Since all
device drivers are essentially standard processes that can register
“callback functions” if you will for handling interrupts, you can
dynamically start and stop just about any driver in the system at any time
without causing any heartburn. Software upgrades become a snap when you can
un-mount your NIC driver then re-mount it in a live system (which basically
shuts it down, then re-runs it). Don’t need that file system any more?
Just nuke it. No video or keyboard? No problem, just don’t run the
drivers. By doing as little work as is necessary at interrupt time, and
using the flexible IPC mechanisms to relay a message to the driver back at
the standard process level indicating the event that just occurred, you can
keep latencies to a minimum and use the available priority and scheduling
algorithms to achieve the system-wide load balancing functionality you
require. If a driver goes bad, it can still do evil things at interrupt
time, but by minimizing that processing window, you can greatly improve the
overall reliability of your code. Even without the DDK’s on the way from
QNX, writing hardware drivers is a treat in that environment since the O.S.
will effectively get out of your way when you need it to, yet you have the
power of all of the standard O.S. facilities at your disposal should you
want them. And if things do go horribly wrong, it’s very likely that your
driver may die and there will be no ill effect on the remainder of the
system. Combine these features with the shared object support, and you can
produce some amazing functionality in a tiny, tiny footprint.

While QNX4 tended to be a little on the difficult side to embed on custom
hardware, QNX6 has addressed this issue in a most impressive manner. In a
totally BIOS-less environment, you merely write an initial program loader
(IPL) and customize a startup module, and you have all of the power and
flexibility of the entire O.S. at your fingertips. The IPL need only
establish enough of a processing environment to allow the startup module to
be run. This includes such things as configuring chipsets, paging in your
non-volatile storage if necessary and so on. Alternatively you can do
virtually all of the setup in the IPL and merely tidy up a bit in the
startup module and fill in the requisite system page structures to let the
O.S. know what it’s got to work with- it’s your choice. The IPL does basic
system setup and loads the startup module, the startup module fills in the
system structures and finishes up any initialization that the IPL didn’t
want to do, then the kernel is started and from there it’s all up to the
“build” file configuration as to what gets run. It’s a beautiful thing,
considering the amount of functionality you can pack into as little as 384K
of FLASH (this is the size of my current 486 O.S. image which gives me a
login shell via RS-232 with 3 or 4 utilities). If you have a BIOS then it’s
not really any different than customizing the build file for a standard PC
implementation. But you really don’t need a BIOS unless you just don’t like
configuring PCI or plug & pray hardware since once running, the O.S. doesn’t
make any BIOS calls anyway (with the notable exception perhaps of some video
mode switching). Once you tweak the IPL & startup code, you can find your
super miniature embedded controller spewing data to your big-ol’ desktop
servers via TCP/IP, QNET or perhaps some custom communication driver you
developed. You can make it serve up web pages, mount remote file systems
over a network, or anything else that you see a full-blown desktop system
doing. Grow only the pieces you need, as large as you need, and leave the
excess baggage behind.

The really beautiful thing about the QNX O.S. is that if you don’t like the
functionality of some of the pieces of it, you can write your own resource
manager that acts the way you want and “splice” it into the system so
seamlessly nobody would ever know it wasn’t supposed to act that way all the
time. If QNET just isn’t cutting it for you in some way, you can either
fall back to TCP/IP (and I do mean “back”), or you can simply roll your
own protocol into a resource manager that talks to the hardware of your
choice and you’ve now got exactly what you need. Want the standard O.S.
networking facilities but over some bizarre unsupported medium? Grab the
network DDK, and you can concentrate on the hardware interface because the
O.S. interface is all taken care of for you. Want your own custom
facilities over different available media? Write a resource manager using
the io-net interface as defined in the DDK and simply “plug in” the standard
devn-* drivers and go for it. The key word is flexibility. You can
integrate your custom features at almost any level of the O.S. because of
the unique message-passing architecture. You won’t find yourself stuck in a
corner wondering “How the heck am I going to do THAT?”. More likely than
not, once some of the concepts of what you can accomplish hit you, you’ll be
saying “I can do THAT?”

If you’re going to give QNX a go, then make sure you take the time to really
look into how you can capitalize on all of the unique features of the O.S.
instead of simply porting some existing application and comparing it against
a VxWorks implementation. You’d be missing the boat entirely, in my
opinion.

Cheers!

-Warren “no I don’t work for QNX” Peece



“Joseph A. Dziedzic” <tonydz@mediaone.net> wrote in message
news:rsKf6.496$wL6.157127@typhoon.ne.mediaone.net…

I’m considering QNX for a future project that my company will be
developing.
I’m curious about opinions about QNX in general and QNX when compared to
other
RTOSes (VxWorks, OSE, OS-9, Nucleus, LynxOS). For those of you who have
developed commercial-scale products using QNX, what were your opinions of
QNX
after having completed a project? Would you use it again? What about
QNET?
Was it as useful for peer-to-peer communications as it appears to be from
the
glossy marketing stuff?

I’d appreciate any feedback - positive and negative - that anyone would
care
to provide. Replies to this post would be welcome - if you’d prefer to
send
e-mail, that would be fine too.

Thanks,
Joseph Dziedzic
Adaptec NTC

[Warren_Peece1]

P.S. - Sorry for the poor spelling & grammer in places, lack of caffeine…



“Warren Peece” <warren@nospam.com> wrote in message
news:95vkdn$7aa$1@inn.qnx.com…

I’ve been using QNX for a long, long time (started with QNX2 back in the
80’s) and I can’t say enough great things about it to do any justice.
First
off, if you take a look at it from the standpoint of someone who has been
doing development on “traditional” systems for any length of time, it’s
extremely easy to overlook or undervalue some of QNX’s strongest
attributes.
Speaking specifically of QNX6 (Neutrino, RtP, whatever you like to call
it)
since you mentioned QNET, on the outside it appears a lot like your
standard
“Un*x-like” O.S. due to the GNU tool set, availability of X, and so on.
Indeed you can use your standard approach to developing monolithic
applications if you should so choose, and the O.S. will perform
wonderfully-
arguably as good or better depending of course on specific circumstances
than anything else out there today. It’s not until you’ve grown
accustomed
to the extreme flexibility, reliability and modularity that embracing the
message-passing philosophy in the initial concepts of your designs that
you’ll realize exactly what you’ve found. By breaking extremely complex
applications down into a group of cooperating processes utilizing IPC for
coordination, you can isolate specific functionality into small modules
with
a well defined interface. If the functionality requirements change, you
can
address the changes in the affected module(s), and leave the remainder of
the system unaltered. If you experience problems in a module that cause
it
to fail for some reason, the remaining modules will continue to run and
you
can make provisions for them to detect the loss of the faulty module and
take corrective action if you should so desire. Perhaps in a given
implementation expansion is a consideration which may be addressed by
simply
invoking multiple instances of certain modules, and if overall system
throughput becomes important you can distribute various modules across
multiple machines interconnected with QNET. While I won’t go so far as to
say there’s no difference between writing a multiple process application
designed to run on a single node vs. across QNET, the considerations are
minor enough to allow you to expand or contract to as many or as few
processing nodes as required without having to make any drastic changes.
While it’s certainly true that you can accomplish the same sort of thing
with other O.S.'s, it will remain a foreign sort of environment while in
QNX
it’s merely a natural extension of the O.S. itsself. In fact, I dread the
thought of having to develop under traditional architecture systems
because
I’ve become accustomed to the power and flexibility of the QNX resource
manager implementation and message passing methodology.

Heading down into the embedded realm, the QNX architecture again can look
as
much like a “standard” O.S. as you like. If you dig a little deeper
however, you start to discover some very powerful features. Since all
device drivers are essentially standard processes that can register
“callback functions” if you will for handling interrupts, you can
dynamically start and stop just about any driver in the system at any time
without causing any heartburn. Software upgrades become a snap when you
can
un-mount your NIC driver then re-mount it in a live system (which
basically
shuts it down, then re-runs it). Don’t need that file system any more?
Just nuke it. No video or keyboard? No problem, just don’t run the
drivers. By doing as little work as is necessary at interrupt time, and
using the flexible IPC mechanisms to relay a message to the driver back at
the standard process level indicating the event that just occurred, you
can
keep latencies to a minimum and use the available priority and scheduling
algorithms to achieve the system-wide load balancing functionality you
require. If a driver goes bad, it can still do evil things at interrupt
time, but by minimizing that processing window, you can greatly improve
the
overall reliability of your code. Even without the DDK’s on the way from
QNX, writing hardware drivers is a treat in that environment since the
O.S.
will effectively get out of your way when you need it to, yet you have the
power of all of the standard O.S. facilities at your disposal should you
want them. And if things do go horribly wrong, it’s very likely that your
driver may die and there will be no ill effect on the remainder of the
system. Combine these features with the shared object support, and you
can
produce some amazing functionality in a tiny, tiny footprint.

While QNX4 tended to be a little on the difficult side to embed on custom
hardware, QNX6 has addressed this issue in a most impressive manner. In a
totally BIOS-less environment, you merely write an initial program loader
(IPL) and customize a startup module, and you have all of the power and
flexibility of the entire O.S. at your fingertips. The IPL need only
establish enough of a processing environment to allow the startup module
to
be run. This includes such things as configuring chipsets, paging in your
non-volatile storage if necessary and so on. Alternatively you can do
virtually all of the setup in the IPL and merely tidy up a bit in the
startup module and fill in the requisite system page structures to let the
O.S. know what it’s got to work with- it’s your choice. The IPL does
basic
system setup and loads the startup module, the startup module fills in the
system structures and finishes up any initialization that the IPL didn’t
want to do, then the kernel is started and from there it’s all up to the
“build” file configuration as to what gets run. It’s a beautiful thing,
considering the amount of functionality you can pack into as little as
384K
of FLASH (this is the size of my current 486 O.S. image which gives me a
login shell via RS-232 with 3 or 4 utilities). If you have a BIOS then
it’s
not really any different than customizing the build file for a standard PC
implementation. But you really don’t need a BIOS unless you just don’t
like
configuring PCI or plug & pray hardware since once running, the O.S.
doesn’t
make any BIOS calls anyway (with the notable exception perhaps of some
video
mode switching). Once you tweak the IPL & startup code, you can find your
super miniature embedded controller spewing data to your big-ol’ desktop
servers via TCP/IP, QNET or perhaps some custom communication driver you
developed. You can make it serve up web pages, mount remote file systems
over a network, or anything else that you see a full-blown desktop system
doing. Grow only the pieces you need, as large as you need, and leave the
excess baggage behind.

The really beautiful thing about the QNX O.S. is that if you don’t like
the
functionality of some of the pieces of it, you can write your own resource
manager that acts the way you want and “splice” it into the system so
seamlessly nobody would ever know it wasn’t supposed to act that way all
the
time. If QNET just isn’t cutting it for you in some way, you can either
fall back to TCP/IP (and I do mean “back”), or you can simply roll your
own protocol into a resource manager that talks to the hardware of your
choice and you’ve now got exactly what you need. Want the standard O.S.
networking facilities but over some bizarre unsupported medium? Grab the
network DDK, and you can concentrate on the hardware interface because the
O.S. interface is all taken care of for you. Want your own custom
facilities over different available media? Write a resource manager using
the io-net interface as defined in the DDK and simply “plug in” the
standard
devn-* drivers and go for it. The key word is flexibility. You can
integrate your custom features at almost any level of the O.S. because of
the unique message-passing architecture. You won’t find yourself stuck in
a
corner wondering “How the heck am I going to do THAT?”. More likely than
not, once some of the concepts of what you can accomplish hit you, you’ll
be
saying “I can do THAT?”

If you’re going to give QNX a go, then make sure you take the time to
really
look into how you can capitalize on all of the unique features of the O.S.
instead of simply porting some existing application and comparing it
against
a VxWorks implementation. You’d be missing the boat entirely, in my
opinion.

Cheers!

-Warren “no I don’t work for QNX” Peece



“Joseph A. Dziedzic” <> tonydz@mediaone.net> > wrote in message
news:rsKf6.496$> wL6.157127@typhoon.ne.mediaone.net> …
I’m considering QNX for a future project that my company will be
developing.
I’m curious about opinions about QNX in general and QNX when compared to
other
RTOSes (VxWorks, OSE, OS-9, Nucleus, LynxOS). For those of you who have
developed commercial-scale products using QNX, what were your opinions
of
QNX
after having completed a project? Would you use it again? What about
QNET?
Was it as useful for peer-to-peer communications as it appears to be
from
the
glossy marketing stuff?

I’d appreciate any feedback - positive and negative - that anyone would
care
to provide. Replies to this post would be welcome - if you’d prefer to
send
e-mail, that would be fine too.

Thanks,
Joseph Dziedzic
Adaptec NTC

[Marty_Doane1]

Great post Warren. Thanks for taking the time to compose it.

Marty

“Warren Peece” <warren@nospam.com> wrote in message
news:95vkdn$7aa$1@inn.qnx.com…

I’ve been using QNX for a long, long time (started with QNX2 back in the
80’s) and I can’t say enough great things about it to do any justice.
First
off, if you take a look at it from the standpoint of someone who has been
doing development on “traditional” systems for any length of time, it’s
extremely easy to overlook or undervalue some of QNX’s strongest
attributes.
Speaking specifically of QNX6 (Neutrino, RtP, whatever you like to call
it)
since you mentioned QNET, on the outside it appears a lot like your
standard
“Un*x-like” O.S. due to the GNU tool set, availability of X, and so on.
Indeed you can use your standard approach to developing monolithic
applications if you should so choose, and the O.S. will perform
wonderfully-
arguably as good or better depending of course on specific circumstances
than anything else out there today. It’s not until you’ve grown
accustomed
to the extreme flexibility, reliability and modularity that embracing the
message-passing philosophy in the initial concepts of your designs that
you’ll realize exactly what you’ve found. By breaking extremely complex
applications down into a group of cooperating processes utilizing IPC for
coordination, you can isolate specific functionality into small modules
with
a well defined interface. If the functionality requirements change, you
can
address the changes in the affected module(s), and leave the remainder of
the system unaltered. If you experience problems in a module that cause
it
to fail for some reason, the remaining modules will continue to run and
you
can make provisions for them to detect the loss of the faulty module and
take corrective action if you should so desire. Perhaps in a given
implementation expansion is a consideration which may be addressed by
simply
invoking multiple instances of certain modules, and if overall system
throughput becomes important you can distribute various modules across
multiple machines interconnected with QNET. While I won’t go so far as to
say there’s no difference between writing a multiple process application
designed to run on a single node vs. across QNET, the considerations are
minor enough to allow you to expand or contract to as many or as few
processing nodes as required without having to make any drastic changes.
While it’s certainly true that you can accomplish the same sort of thing
with other O.S.'s, it will remain a foreign sort of environment while in
QNX
it’s merely a natural extension of the O.S. itsself. In fact, I dread the
thought of having to develop under traditional architecture systems
because
I’ve become accustomed to the power and flexibility of the QNX resource
manager implementation and message passing methodology.

Heading down into the embedded realm, the QNX architecture again can look
as
much like a “standard” O.S. as you like. If you dig a little deeper
however, you start to discover some very powerful features. Since all
device drivers are essentially standard processes that can register
“callback functions” if you will for handling interrupts, you can
dynamically start and stop just about any driver in the system at any time
without causing any heartburn. Software upgrades become a snap when you
can
un-mount your NIC driver then re-mount it in a live system (which
basically
shuts it down, then re-runs it). Don’t need that file system any more?
Just nuke it. No video or keyboard? No problem, just don’t run the
drivers. By doing as little work as is necessary at interrupt time, and
using the flexible IPC mechanisms to relay a message to the driver back at
the standard process level indicating the event that just occurred, you
can
keep latencies to a minimum and use the available priority and scheduling
algorithms to achieve the system-wide load balancing functionality you
require. If a driver goes bad, it can still do evil things at interrupt
time, but by minimizing that processing window, you can greatly improve
the
overall reliability of your code. Even without the DDK’s on the way from
QNX, writing hardware drivers is a treat in that environment since the
O.S.
will effectively get out of your way when you need it to, yet you have the
power of all of the standard O.S. facilities at your disposal should you
want them. And if things do go horribly wrong, it’s very likely that your
driver may die and there will be no ill effect on the remainder of the
system. Combine these features with the shared object support, and you
can
produce some amazing functionality in a tiny, tiny footprint.

While QNX4 tended to be a little on the difficult side to embed on custom
hardware, QNX6 has addressed this issue in a most impressive manner. In a
totally BIOS-less environment, you merely write an initial program loader
(IPL) and customize a startup module, and you have all of the power and
flexibility of the entire O.S. at your fingertips. The IPL need only
establish enough of a processing environment to allow the startup module
to
be run. This includes such things as configuring chipsets, paging in your
non-volatile storage if necessary and so on. Alternatively you can do
virtually all of the setup in the IPL and merely tidy up a bit in the
startup module and fill in the requisite system page structures to let the
O.S. know what it’s got to work with- it’s your choice. The IPL does
basic
system setup and loads the startup module, the startup module fills in the
system structures and finishes up any initialization that the IPL didn’t
want to do, then the kernel is started and from there it’s all up to the
“build” file configuration as to what gets run. It’s a beautiful thing,
considering the amount of functionality you can pack into as little as
384K
of FLASH (this is the size of my current 486 O.S. image which gives me a
login shell via RS-232 with 3 or 4 utilities). If you have a BIOS then
it’s
not really any different than customizing the build file for a standard PC
implementation. But you really don’t need a BIOS unless you just don’t
like
configuring PCI or plug & pray hardware since once running, the O.S.
doesn’t
make any BIOS calls anyway (with the notable exception perhaps of some
video
mode switching). Once you tweak the IPL & startup code, you can find your
super miniature embedded controller spewing data to your big-ol’ desktop
servers via TCP/IP, QNET or perhaps some custom communication driver you
developed. You can make it serve up web pages, mount remote file systems
over a network, or anything else that you see a full-blown desktop system
doing. Grow only the pieces you need, as large as you need, and leave the
excess baggage behind.

The really beautiful thing about the QNX O.S. is that if you don’t like
the
functionality of some of the pieces of it, you can write your own resource
manager that acts the way you want and “splice” it into the system so
seamlessly nobody would ever know it wasn’t supposed to act that way all
the
time. If QNET just isn’t cutting it for you in some way, you can either
fall back to TCP/IP (and I do mean “back”), or you can simply roll your
own protocol into a resource manager that talks to the hardware of your
choice and you’ve now got exactly what you need. Want the standard O.S.
networking facilities but over some bizarre unsupported medium? Grab the
network DDK, and you can concentrate on the hardware interface because the
O.S. interface is all taken care of for you. Want your own custom
facilities over different available media? Write a resource manager using
the io-net interface as defined in the DDK and simply “plug in” the
standard
devn-* drivers and go for it. The key word is flexibility. You can
integrate your custom features at almost any level of the O.S. because of
the unique message-passing architecture. You won’t find yourself stuck in
a
corner wondering “How the heck am I going to do THAT?”. More likely than
not, once some of the concepts of what you can accomplish hit you, you’ll
be
saying “I can do THAT?”

If you’re going to give QNX a go, then make sure you take the time to
really
look into how you can capitalize on all of the unique features of the O.S.
instead of simply porting some existing application and comparing it
against
a VxWorks implementation. You’d be missing the boat entirely, in my
opinion.

Cheers!

-Warren “no I don’t work for QNX” Peece



“Joseph A. Dziedzic” <> tonydz@mediaone.net> > wrote in message
news:rsKf6.496$> wL6.157127@typhoon.ne.mediaone.net> …
I’m considering QNX for a future project that my company will be
developing.
I’m curious about opinions about QNX in general and QNX when compared to
other
RTOSes (VxWorks, OSE, OS-9, Nucleus, LynxOS). For those of you who have
developed commercial-scale products using QNX, what were your opinions
of
QNX
after having completed a project? Would you use it again? What about
QNET?
Was it as useful for peer-to-peer communications as it appears to be
from
the
glossy marketing stuff?

I’d appreciate any feedback - positive and negative - that anyone would
care
to provide. Replies to this post would be welcome - if you’d prefer to
send
e-mail, that would be fine too.

Thanks,
Joseph Dziedzic
Adaptec NTC

[Igor_Kovalenko2]

Oh man! You take your passion seriously, don’t you?
I suddently feel an urge to post some negative experiences
Somebody hold me, don’t let me do it!

Warren Peece wrote:

I’ve been using QNX for a long, long time (started with QNX2 back in the
80’s) and I can’t say enough great things about it to do any justice. First
off, if you take a look at it from the standpoint of someone who has been
doing development on “traditional” systems for any length of time, it’s
extremely easy to overlook or undervalue some of QNX’s strongest attributes.
Speaking specifically of QNX6 (Neutrino, RtP, whatever you like to call it)
since you mentioned QNET, on the outside it appears a lot like your standard
“Un*x-like” O.S. due to the GNU tool set, availability of X, and so on.
Indeed you can use your standard approach to developing monolithic
applications if you should so choose, and the O.S. will perform wonderfully-
arguably as good or better depending of course on specific circumstances
than anything else out there today. It’s not until you’ve grown accustomed
to the extreme flexibility, reliability and modularity that embracing the
message-passing philosophy in the initial concepts of your designs that
you’ll realize exactly what you’ve found. By breaking extremely complex
applications down into a group of cooperating processes utilizing IPC for
coordination, you can isolate specific functionality into small modules with
a well defined interface. If the functionality requirements change, you can
address the changes in the affected module(s), and leave the remainder of
the system unaltered. If you experience problems in a module that cause it
to fail for some reason, the remaining modules will continue to run and you
can make provisions for them to detect the loss of the faulty module and
take corrective action if you should so desire. Perhaps in a given
implementation expansion is a consideration which may be addressed by simply
invoking multiple instances of certain modules, and if overall system
throughput becomes important you can distribute various modules across
multiple machines interconnected with QNET. While I won’t go so far as to
say there’s no difference between writing a multiple process application
designed to run on a single node vs. across QNET, the considerations are
minor enough to allow you to expand or contract to as many or as few
processing nodes as required without having to make any drastic changes.
While it’s certainly true that you can accomplish the same sort of thing
with other O.S.'s, it will remain a foreign sort of environment while in QNX
it’s merely a natural extension of the O.S. itsself. In fact, I dread the
thought of having to develop under traditional architecture systems because
I’ve become accustomed to the power and flexibility of the QNX resource
manager implementation and message passing methodology.

Heading down into the embedded realm, the QNX architecture again can look as
much like a “standard” O.S. as you like. If you dig a little deeper
however, you start to discover some very powerful features. Since all
device drivers are essentially standard processes that can register
“callback functions” if you will for handling interrupts, you can
dynamically start and stop just about any driver in the system at any time
without causing any heartburn. Software upgrades become a snap when you can
un-mount your NIC driver then re-mount it in a live system (which basically
shuts it down, then re-runs it). Don’t need that file system any more?
Just nuke it. No video or keyboard? No problem, just don’t run the
drivers. By doing as little work as is necessary at interrupt time, and
using the flexible IPC mechanisms to relay a message to the driver back at
the standard process level indicating the event that just occurred, you can
keep latencies to a minimum and use the available priority and scheduling
algorithms to achieve the system-wide load balancing functionality you
require. If a driver goes bad, it can still do evil things at interrupt
time, but by minimizing that processing window, you can greatly improve the
overall reliability of your code. Even without the DDK’s on the way from
QNX, writing hardware drivers is a treat in that environment since the O.S.
will effectively get out of your way when you need it to, yet you have the
power of all of the standard O.S. facilities at your disposal should you
want them. And if things do go horribly wrong, it’s very likely that your
driver may die and there will be no ill effect on the remainder of the
system. Combine these features with the shared object support, and you can
produce some amazing functionality in a tiny, tiny footprint.

While QNX4 tended to be a little on the difficult side to embed on custom
hardware, QNX6 has addressed this issue in a most impressive manner. In a
totally BIOS-less environment, you merely write an initial program loader
(IPL) and customize a startup module, and you have all of the power and
flexibility of the entire O.S. at your fingertips. The IPL need only
establish enough of a processing environment to allow the startup module to
be run. This includes such things as configuring chipsets, paging in your
non-volatile storage if necessary and so on. Alternatively you can do
virtually all of the setup in the IPL and merely tidy up a bit in the
startup module and fill in the requisite system page structures to let the
O.S. know what it’s got to work with- it’s your choice. The IPL does basic
system setup and loads the startup module, the startup module fills in the
system structures and finishes up any initialization that the IPL didn’t
want to do, then the kernel is started and from there it’s all up to the
“build” file configuration as to what gets run. It’s a beautiful thing,
considering the amount of functionality you can pack into as little as 384K
of FLASH (this is the size of my current 486 O.S. image which gives me a
login shell via RS-232 with 3 or 4 utilities). If you have a BIOS then it’s
not really any different than customizing the build file for a standard PC
implementation. But you really don’t need a BIOS unless you just don’t like
configuring PCI or plug & pray hardware since once running, the O.S. doesn’t
make any BIOS calls anyway (with the notable exception perhaps of some video
mode switching). Once you tweak the IPL & startup code, you can find your
super miniature embedded controller spewing data to your big-ol’ desktop
servers via TCP/IP, QNET or perhaps some custom communication driver you
developed. You can make it serve up web pages, mount remote file systems
over a network, or anything else that you see a full-blown desktop system
doing. Grow only the pieces you need, as large as you need, and leave the
excess baggage behind.

The really beautiful thing about the QNX O.S. is that if you don’t like the
functionality of some of the pieces of it, you can write your own resource
manager that acts the way you want and “splice” it into the system so
seamlessly nobody would ever know it wasn’t supposed to act that way all the
time. If QNET just isn’t cutting it for you in some way, you can either
fall back to TCP/IP (and I do mean “back”), or you can simply roll your
own protocol into a resource manager that talks to the hardware of your
choice and you’ve now got exactly what you need. Want the standard O.S.
networking facilities but over some bizarre unsupported medium? Grab the
network DDK, and you can concentrate on the hardware interface because the
O.S. interface is all taken care of for you. Want your own custom
facilities over different available media? Write a resource manager using
the io-net interface as defined in the DDK and simply “plug in” the standard
devn-* drivers and go for it. The key word is flexibility. You can
integrate your custom features at almost any level of the O.S. because of
the unique message-passing architecture. You won’t find yourself stuck in a
corner wondering “How the heck am I going to do THAT?”. More likely than
not, once some of the concepts of what you can accomplish hit you, you’ll be
saying “I can do THAT?”

If you’re going to give QNX a go, then make sure you take the time to really
look into how you can capitalize on all of the unique features of the O.S.
instead of simply porting some existing application and comparing it against
a VxWorks implementation. You’d be missing the boat entirely, in my
opinion.

Cheers!

-Warren “no I don’t work for QNX” Peece

“Joseph A. Dziedzic” <> tonydz@mediaone.net> > wrote in message
news:rsKf6.496$> wL6.157127@typhoon.ne.mediaone.net> …
I’m considering QNX for a future project that my company will be
developing.
I’m curious about opinions about QNX in general and QNX when compared to
other
RTOSes (VxWorks, OSE, OS-9, Nucleus, LynxOS). For those of you who have
developed commercial-scale products using QNX, what were your opinions of
QNX
after having completed a project? Would you use it again? What about
QNET?
Was it as useful for peer-to-peer communications as it appears to be from
the
glossy marketing stuff?

I’d appreciate any feedback - positive and negative - that anyone would
care
to provide. Replies to this post would be welcome - if you’d prefer to
send
e-mail, that would be fine too.

Thanks,
Joseph Dziedzic
Adaptec NTC

[Steve_Munnings_Corma]

Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote in message
news:3A845208.78C6D481@motorola.com…

Oh man! You take your passion seriously, don’t you?
I suddently feel an urge to post some negative experiences >
Somebody hold me, don’t let me do it!

He is posting from the viewpoint of an architectural overview of the system.
I agree with his take on it’s inherent superiorities!

ALL, repeat ALL, OSes will give any serious developer negative
experiences - just about all the time!
The complication of the systems is just so great that it is almost
inevitable.

But nobody { well, except maybe you, Igor, and maybe Armin, and a whole
bunch of other guys 8-} really wants to dwell on the negative experiences.
It is just a fact of life that one deals with. For that matter the number
of negative experiences is much lower (in my experience) with QNX than with
some (much better known) others, but it is not necessarily alone in its
level of quality.

Warren Peece wrote:

I’ve been using QNX for a long, long time (started with QNX2 back in the
80’s) and I can’t say enough great things about it to do any justice.
First
off, if you take a look at it from the standpoint of someone who has
been
doing development on “traditional” systems for any length of time, it’s
extremely easy to overlook or undervalue some of QNX’s strongest
attributes.
Speaking specifically of QNX6 (Neutrino, RtP, whatever you like to call
it)
since you mentioned QNET, on the outside it appears a lot like your
standard
“Un*x-like” O.S. due to the GNU tool set, availability of X, and so on.
Indeed you can use your standard approach to developing monolithic
applications if you should so choose, and the O.S. will perform
wonderfully-
arguably as good or better depending of course on specific circumstances
than anything else out there today. It’s not until you’ve grown
accustomed
to the extreme flexibility, reliability and modularity that embracing
the
message-passing philosophy in the initial concepts of your designs that
you’ll realize exactly what you’ve found. By breaking extremely complex
applications down into a group of cooperating processes utilizing IPC
for
coordination, you can isolate specific functionality into small modules
with
a well defined interface. If the functionality requirements change, you
can
address the changes in the affected module(s), and leave the remainder
of
the system unaltered. If you experience problems in a module that cause
it
to fail for some reason, the remaining modules will continue to run and
you
can make provisions for them to detect the loss of the faulty module and
take corrective action if you should so desire. Perhaps in a given
implementation expansion is a consideration which may be addressed by
simply
invoking multiple instances of certain modules, and if overall system
throughput becomes important you can distribute various modules across
multiple machines interconnected with QNET. While I won’t go so far as
to
say there’s no difference between writing a multiple process application
designed to run on a single node vs. across QNET, the considerations are
minor enough to allow you to expand or contract to as many or as few
processing nodes as required without having to make any drastic changes.
While it’s certainly true that you can accomplish the same sort of thing
with other O.S.'s, it will remain a foreign sort of environment while in
QNX
it’s merely a natural extension of the O.S. itsself. In fact, I dread
the
thought of having to develop under traditional architecture systems
because
I’ve become accustomed to the power and flexibility of the QNX resource
manager implementation and message passing methodology.

Heading down into the embedded realm, the QNX architecture again can
look as
much like a “standard” O.S. as you like. If you dig a little deeper
however, you start to discover some very powerful features. Since all
device drivers are essentially standard processes that can register
“callback functions” if you will for handling interrupts, you can
dynamically start and stop just about any driver in the system at any
time
without causing any heartburn. Software upgrades become a snap when you
can
un-mount your NIC driver then re-mount it in a live system (which
basically
shuts it down, then re-runs it). Don’t need that file system any more?
Just nuke it. No video or keyboard? No problem, just don’t run the
drivers. By doing as little work as is necessary at interrupt time, and
using the flexible IPC mechanisms to relay a message to the driver back
at
the standard process level indicating the event that just occurred, you
can
keep latencies to a minimum and use the available priority and
scheduling
algorithms to achieve the system-wide load balancing functionality you
require. If a driver goes bad, it can still do evil things at interrupt
time, but by minimizing that processing window, you can greatly improve
the
overall reliability of your code. Even without the DDK’s on the way
from
QNX, writing hardware drivers is a treat in that environment since the
O.S.
will effectively get out of your way when you need it to, yet you have
the
power of all of the standard O.S. facilities at your disposal should you
want them. And if things do go horribly wrong, it’s very likely that
your
driver may die and there will be no ill effect on the remainder of the
system. Combine these features with the shared object support, and you
can
produce some amazing functionality in a tiny, tiny footprint.

While QNX4 tended to be a little on the difficult side to embed on
custom
hardware, QNX6 has addressed this issue in a most impressive manner. In
a
totally BIOS-less environment, you merely write an initial program
loader
(IPL) and customize a startup module, and you have all of the power and
flexibility of the entire O.S. at your fingertips. The IPL need only
establish enough of a processing environment to allow the startup module
to
be run. This includes such things as configuring chipsets, paging in
your
non-volatile storage if necessary and so on. Alternatively you can do
virtually all of the setup in the IPL and merely tidy up a bit in the
startup module and fill in the requisite system page structures to let
the
O.S. know what it’s got to work with- it’s your choice. The IPL does
basic
system setup and loads the startup module, the startup module fills in
the
system structures and finishes up any initialization that the IPL didn’t
want to do, then the kernel is started and from there it’s all up to the
“build” file configuration as to what gets run. It’s a beautiful thing,
considering the amount of functionality you can pack into as little as
384K
of FLASH (this is the size of my current 486 O.S. image which gives me a
login shell via RS-232 with 3 or 4 utilities). If you have a BIOS then
it’s
not really any different than customizing the build file for a standard
PC
implementation. But you really don’t need a BIOS unless you just don’t
like
configuring PCI or plug & pray hardware since once running, the O.S.
doesn’t
make any BIOS calls anyway (with the notable exception perhaps of some
video
mode switching). Once you tweak the IPL & startup code, you can find
your
super miniature embedded controller spewing data to your big-ol’ desktop
servers via TCP/IP, QNET or perhaps some custom communication driver you
developed. You can make it serve up web pages, mount remote file
systems
over a network, or anything else that you see a full-blown desktop
system
doing. Grow only the pieces you need, as large as you need, and leave
the
excess baggage behind.

The really beautiful thing about the QNX O.S. is that if you don’t like
the
functionality of some of the pieces of it, you can write your own
resource
manager that acts the way you want and “splice” it into the system so
seamlessly nobody would ever know it wasn’t supposed to act that way all
the
time. If QNET just isn’t cutting it for you in some way, you can either
fall back to TCP/IP (and I do mean “back”), or you can simply roll
your
own protocol into a resource manager that talks to the hardware of your
choice and you’ve now got exactly what you need. Want the standard O.S.
networking facilities but over some bizarre unsupported medium? Grab
the
network DDK, and you can concentrate on the hardware interface because
the
O.S. interface is all taken care of for you. Want your own custom
facilities over different available media? Write a resource manager
using
the io-net interface as defined in the DDK and simply “plug in” the
standard
devn-* drivers and go for it. The key word is flexibility. You can
integrate your custom features at almost any level of the O.S. because
of
the unique message-passing architecture. You won’t find yourself stuck
in a
corner wondering “How the heck am I going to do THAT?”. More likely
than
not, once some of the concepts of what you can accomplish hit you,
you’ll be
saying “I can do THAT?”

If you’re going to give QNX a go, then make sure you take the time to
really
look into how you can capitalize on all of the unique features of the
O.S.
instead of simply porting some existing application and comparing it
against
a VxWorks implementation. You’d be missing the boat entirely, in my
opinion.

Cheers!

-Warren “no I don’t work for QNX” Peece

“Joseph A. Dziedzic” <> tonydz@mediaone.net> > wrote in message
news:rsKf6.496$> wL6.157127@typhoon.ne.mediaone.net> …
I’m considering QNX for a future project that my company will be
developing.
I’m curious about opinions about QNX in general and QNX when compared
to
other
RTOSes (VxWorks, OSE, OS-9, Nucleus, LynxOS). For those of you who
have
developed commercial-scale products using QNX, what were your opinions
of
QNX
after having completed a project? Would you use it again? What about
QNET?
Was it as useful for peer-to-peer communications as it appears to be
from
the
glossy marketing stuff?

I’d appreciate any feedback - positive and negative - that anyone
would
care
to provide. Replies to this post would be welcome - if you’d prefer
to
send
e-mail, that would be fine too.

Thanks,
Joseph Dziedzic
Adaptec NTC

[Pete_D]

Previously, Steve Munnings, Corman Technologies wrote in comp.os.qnx:

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote in message
news:> 3A845208.78C6D481@motorola.com> …
Oh man! You take your passion seriously, don’t you?
I suddently feel an urge to post some negative experiences >
Somebody hold me, don’t let me do it!


He is posting from the viewpoint of an architectural overview of the system.
I agree with his take on it’s inherent superiorities!

ALL, repeat ALL, OSes will give any serious developer negative
experiences - just about all the time!
The complication of the systems is just so great that it is almost
inevitable.

I’m not so sure. I can imagine some of the wimpy OSes (like pSOS, VxWorks, VRTX, & CP/M) being bug-free… assuming that you don’t count device drivers as part of the OS. VRTX has/had FAA approval (the FAA is the US agency in charge of aircraft safety). But if you want an OS that actually has some functionality, you’re going to have to face the halting problem.

Just my $0.02,

• PDM

[Warren_Peece1]

Heh. I certainly hope you meant “hold me back” and not just “hold me”, Igor

QNX isn’t my passion, it’s what I use to make a living (and yes it’s my
choice- I could choose any hardware platform/O.S. I want). I would never
say that QNX is the perfect answer to every problem, but you’d have to put a
gun to my head to make me switch to Linux RT or anything else for that
matter. Even then I’d have to think pretty hard about it. If QNX went away
I think I’d go wax surfboards in Tahiti for a living instead of wrestling
with the other stuff that’s out there. Color me spoiled (and I don’t mean
like really old cottage cheese, either!). When it comes right down to it,
there’s nothing special about the QNX version of GCC, or the linker, or what
have you. It’s the whole underlying architecture that makes the difference.
I just want to make sure that people at least look under the covers a bit
instead of saying something shallow like “Yep, looks like Linux.” Uhm,
unless of course they’re competing in the same industry as we are, in which
case they should definitely forget everything I said and switch to “Rock
solid, reliable, Windows NT” right now so they can get the jump on us…
Yeah, that’s it, that’s the ticket. Switch to the Dark Side!

-Warren “Darth Vader was married to a woman named Ella” Peece


“Igor Kovalenko” <Igor.Kovalenko@motorola.com> wrote in message
news:3A845208.78C6D481@motorola.com…

Oh man! You take your passion seriously, don’t you?
I suddently feel an urge to post some negative experiences >
Somebody hold me, don’t let me do it!

Warren Peece wrote:

I’ve been using QNX for a long, long time (started with QNX2 back in the
80’s) and I can’t say enough great things about it to do any justice.
First
off, if you take a look at it from the standpoint of someone who has
been
doing development on “traditional” systems for any length of time, it’s
extremely easy to overlook or undervalue some of QNX’s strongest
attributes.
Speaking specifically of QNX6 (Neutrino, RtP, whatever you like to call
it)
since you mentioned QNET, on the outside it appears a lot like your
standard
“Un*x-like” O.S. due to the GNU tool set, availability of X, and so on.
Indeed you can use your standard approach to developing monolithic
applications if you should so choose, and the O.S. will perform
wonderfully-
arguably as good or better depending of course on specific circumstances
than anything else out there today. It’s not until you’ve grown
accustomed
to the extreme flexibility, reliability and modularity that embracing
the
message-passing philosophy in the initial concepts of your designs that
you’ll realize exactly what you’ve found. By breaking extremely complex
applications down into a group of cooperating processes utilizing IPC
for
coordination, you can isolate specific functionality into small modules
with
a well defined interface. If the functionality requirements change, you
can
address the changes in the affected module(s), and leave the remainder
of
the system unaltered. If you experience problems in a module that cause
it
to fail for some reason, the remaining modules will continue to run and
you
can make provisions for them to detect the loss of the faulty module and
take corrective action if you should so desire. Perhaps in a given
implementation expansion is a consideration which may be addressed by
simply
invoking multiple instances of certain modules, and if overall system
throughput becomes important you can distribute various modules across
multiple machines interconnected with QNET. While I won’t go so far as
to
say there’s no difference between writing a multiple process application
designed to run on a single node vs. across QNET, the considerations are
minor enough to allow you to expand or contract to as many or as few
processing nodes as required without having to make any drastic changes.
While it’s certainly true that you can accomplish the same sort of thing
with other O.S.'s, it will remain a foreign sort of environment while in
QNX
it’s merely a natural extension of the O.S. itsself. In fact, I dread
the
thought of having to develop under traditional architecture systems
because
I’ve become accustomed to the power and flexibility of the QNX resource
manager implementation and message passing methodology.

Heading down into the embedded realm, the QNX architecture again can
look as
much like a “standard” O.S. as you like. If you dig a little deeper
however, you start to discover some very powerful features. Since all
device drivers are essentially standard processes that can register
“callback functions” if you will for handling interrupts, you can
dynamically start and stop just about any driver in the system at any
time
without causing any heartburn. Software upgrades become a snap when you
can
un-mount your NIC driver then re-mount it in a live system (which
basically
shuts it down, then re-runs it). Don’t need that file system any more?
Just nuke it. No video or keyboard? No problem, just don’t run the
drivers. By doing as little work as is necessary at interrupt time, and
using the flexible IPC mechanisms to relay a message to the driver back
at
the standard process level indicating the event that just occurred, you
can
keep latencies to a minimum and use the available priority and
scheduling
algorithms to achieve the system-wide load balancing functionality you
require. If a driver goes bad, it can still do evil things at interrupt
time, but by minimizing that processing window, you can greatly improve
the
overall reliability of your code. Even without the DDK’s on the way
from
QNX, writing hardware drivers is a treat in that environment since the
O.S.
will effectively get out of your way when you need it to, yet you have
the
power of all of the standard O.S. facilities at your disposal should you
want them. And if things do go horribly wrong, it’s very likely that
your
driver may die and there will be no ill effect on the remainder of the
system. Combine these features with the shared object support, and you
can
produce some amazing functionality in a tiny, tiny footprint.

While QNX4 tended to be a little on the difficult side to embed on
custom
hardware, QNX6 has addressed this issue in a most impressive manner. In
a
totally BIOS-less environment, you merely write an initial program
loader
(IPL) and customize a startup module, and you have all of the power and
flexibility of the entire O.S. at your fingertips. The IPL need only
establish enough of a processing environment to allow the startup module
to
be run. This includes such things as configuring chipsets, paging in
your
non-volatile storage if necessary and so on. Alternatively you can do
virtually all of the setup in the IPL and merely tidy up a bit in the
startup module and fill in the requisite system page structures to let
the
O.S. know what it’s got to work with- it’s your choice. The IPL does
basic
system setup and loads the startup module, the startup module fills in
the
system structures and finishes up any initialization that the IPL didn’t
want to do, then the kernel is started and from there it’s all up to the
“build” file configuration as to what gets run. It’s a beautiful thing,
considering the amount of functionality you can pack into as little as
384K
of FLASH (this is the size of my current 486 O.S. image which gives me a
login shell via RS-232 with 3 or 4 utilities). If you have a BIOS then
it’s
not really any different than customizing the build file for a standard
PC
implementation. But you really don’t need a BIOS unless you just don’t
like
configuring PCI or plug & pray hardware since once running, the O.S.
doesn’t
make any BIOS calls anyway (with the notable exception perhaps of some
video
mode switching). Once you tweak the IPL & startup code, you can find
your
super miniature embedded controller spewing data to your big-ol’ desktop
servers via TCP/IP, QNET or perhaps some custom communication driver you
developed. You can make it serve up web pages, mount remote file
systems
over a network, or anything else that you see a full-blown desktop
system
doing. Grow only the pieces you need, as large as you need, and leave
the
excess baggage behind.

The really beautiful thing about the QNX O.S. is that if you don’t like
the
functionality of some of the pieces of it, you can write your own
resource
manager that acts the way you want and “splice” it into the system so
seamlessly nobody would ever know it wasn’t supposed to act that way all
the
time. If QNET just isn’t cutting it for you in some way, you can either
fall back to TCP/IP (and I do mean “back”), or you can simply roll
your
own protocol into a resource manager that talks to the hardware of your
choice and you’ve now got exactly what you need. Want the standard O.S.
networking facilities but over some bizarre unsupported medium? Grab
the
network DDK, and you can concentrate on the hardware interface because
the
O.S. interface is all taken care of for you. Want your own custom
facilities over different available media? Write a resource manager
using
the io-net interface as defined in the DDK and simply “plug in” the
standard
devn-* drivers and go for it. The key word is flexibility. You can
integrate your custom features at almost any level of the O.S. because
of
the unique message-passing architecture. You won’t find yourself stuck
in a
corner wondering “How the heck am I going to do THAT?”. More likely
than
not, once some of the concepts of what you can accomplish hit you,
you’ll be
saying “I can do THAT?”

If you’re going to give QNX a go, then make sure you take the time to
really
look into how you can capitalize on all of the unique features of the
O.S.
instead of simply porting some existing application and comparing it
against
a VxWorks implementation. You’d be missing the boat entirely, in my
opinion.

Cheers!

-Warren “no I don’t work for QNX” Peece

“Joseph A. Dziedzic” <> tonydz@mediaone.net> > wrote in message
news:rsKf6.496$> wL6.157127@typhoon.ne.mediaone.net> …
I’m considering QNX for a future project that my company will be
developing.
I’m curious about opinions about QNX in general and QNX when compared
to
other
RTOSes (VxWorks, OSE, OS-9, Nucleus, LynxOS). For those of you who
have
developed commercial-scale products using QNX, what were your opinions
of
QNX
after having completed a project? Would you use it again? What about
QNET?
Was it as useful for peer-to-peer communications as it appears to be
from
the
glossy marketing stuff?

I’d appreciate any feedback - positive and negative - that anyone
would
care
to provide. Replies to this post would be welcome - if you’d prefer
to
send
e-mail, that would be fine too.

Thanks,
Joseph Dziedzic
Adaptec NTC

[Armin_Steinhoff1]

“Steve Munnings, Corman Technologies” wrote:

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote in message
news:> 3A845208.78C6D481@motorola.com> …
Oh man! You take your passion seriously, don’t you?
I suddently feel an urge to post some negative experiences >
Somebody hold me, don’t let me do it!


He is posting from the viewpoint of an architectural overview of the system.
I agree with his take on it’s inherent superiorities!

ALL, repeat ALL, OSes will give any serious developer negative
experiences - just about all the time!
The complication of the systems is just so great that it is almost
inevitable.

But nobody { well, except maybe you, Igor, and maybe Armin, and a whole
bunch of other guys 8-} really wants to dwell on the negative experiences.

‘We’ are talking only about negative experiences ? … I’m not
convinced. I would call it ‘realistic feedback’ … and most of it
has a real and hard background in our day by day business as
software developers.

And from an European point of view … honest feedback is better
than polite silence.

Well … sometimes it is realy hard to make positive statements.
For instance: when I try to talk about my positive experiences with
XFree86, how easy it is to port X apps to QNX6 … and how stable
DDD works with XFree86 … or how powerful Qt would be on top of
Photon (what ever it means …) I had here endless debates
Life is hard … you know

However … from an architectural point of view, QNX 6 is a very
promising RTOS … it is much better than QNX 4, IMHO.

Armin

[Mario_Charest1]

“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A852324.CE7C68E0@web_.de…

“Steve Munnings, Corman Technologies” wrote:

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote in message
news:> 3A845208.78C6D481@motorola.com> …
Oh man! You take your passion seriously, don’t you?
I suddently feel an urge to post some negative experiences >
Somebody hold me, don’t let me do it!


He is posting from the viewpoint of an architectural overview of the
system.
I agree with his take on it’s inherent superiorities!

ALL, repeat ALL, OSes will give any serious developer negative
experiences - just about all the time!
The complication of the systems is just so great that it is almost
inevitable.

But nobody { well, except maybe you, Igor, and maybe Armin, and a whole
bunch of other guys 8-} really wants to dwell on the negative
experiences.

‘We’ are talking only about negative experiences ? … I’m not
convinced. I would call it ‘realistic feedback’ … and most of it
has a real and hard background in our day by day business as
software developers.

And from an European point of view … honest feedback is better
than polite silence.

Armin I don’t know you but I would guess you are a dangerous human
being for the next generation to come. You own a car or take the bus, you
probably use
electricity generated from buring fuel or coal. You throw chemical
like paint in the sewer. You probably use soap with phosphore in it?
You flush the toilet every time you use it. You leave some of you
computer/screen
on at night. They don’t know it but my kids should be afraid of you, very
afraid.

I hope you appreciate honest feedback and will make the best of it to
improve who you are. I’m just trying to get in the European spirit.

Well … sometimes it is realy hard to make positive statements.
For instance: when I try to talk about my positive experiences with
XFree86, how easy it is to port X apps to QNX6 … and how stable
DDD works with XFree86 … or how powerful Qt would be on top of
Photon (what ever it means …) I had here endless debates >
Life is hard … you know >

However … from an architectural point of view, QNX 6 is a very
promising RTOS … it is much better than QNX 4, IMHO.

Armin

[Warren_Peece1]

“Mario Charest” <mcharest@void_zinformatic.com> wrote in message
news:Ecxh6.920$Iu3.4360@weber.videotron.net…

[ … ]

You flush the toilet every time you use it.

Do you mean to tell me Europeans don’t flush the toilet? Eeeww!

-Warren “bah-woosh! (Fergusson)” Peece

[Frank_Kolnick]

I hate to see threads – especially QNX threads – take this direction.
Sure, Armin comes across as ‘gruff’ sometimes, but that’s a hard thing to
control in print. And I think he has a point. Any evaluation should be
balanced, and it’s much better to be aware of the limitations of any product
before you encounter them. This forum attracts actual developpers with a
wide range of real experience – good and bad – and I certainly wouldn’t
like to miss out on that. QNX is an ideal o/s, from many points of view,
but I haven’t heard anything about dropping development or tech. support yet

[Obviously, diplomacy isn’t my forte either, but I had to get my 2 pfennings
in.]


“Mario Charest” <mcharest@void_zinformatic.com> wrote in message
news:Ecxh6.920$Iu3.4360@weber.videotron.net…

“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A852324.CE7C68E0@web_.de…


“Steve Munnings, Corman Technologies” wrote:

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote in message
news:> 3A845208.78C6D481@motorola.com> …
Oh man! You take your passion seriously, don’t you?
I suddently feel an urge to post some negative experiences >
Somebody hold me, don’t let me do it!


He is posting from the viewpoint of an architectural overview of the
system.
I agree with his take on it’s inherent superiorities!

ALL, repeat ALL, OSes will give any serious developer negative
experiences - just about all the time!
The complication of the systems is just so great that it is almost
inevitable.

But nobody { well, except maybe you, Igor, and maybe Armin, and a
whole
bunch of other guys 8-} really wants to dwell on the negative
experiences.

‘We’ are talking only about negative experiences ? … I’m not
convinced. I would call it ‘realistic feedback’ … and most of it
has a real and hard background in our day by day business as
software developers.

And from an European point of view … honest feedback is better
than polite silence.


Armin I don’t know you but I would guess you are a dangerous human
being for the next generation to come. You own a car or take the bus, you
probably use
electricity generated from buring fuel or coal. You throw chemical
like paint in the sewer. You probably use soap with phosphore in it?
You flush the toilet every time you use it. You leave some of you
computer/screen
on at night. They don’t know it but my kids should be afraid of you, very
afraid.

I hope you appreciate honest feedback and will make the best of it to
improve who you are. I’m just trying to get in the European spirit.


Well … sometimes it is realy hard to make positive statements.
For instance: when I try to talk about my positive experiences with
XFree86, how easy it is to port X apps to QNX6 … and how stable
DDD works with XFree86 … or how powerful Qt would be on top of
Photon (what ever it means …) I had here endless debates >
Life is hard … you know >

However … from an architectural point of view, QNX 6 is a very
promising RTOS … it is much better than QNX 4, IMHO.

Armin

[Jutta_Steinhoff1]

Mario Charest wrote:

“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A852324.CE7C68E0@web_.de…

“Steve Munnings, Corman Technologies” wrote:

[…]

But nobody { well, except maybe you, Igor, and maybe Armin, and a whole
bunch of other guys 8-} really wants to dwell on the negative
experiences.

‘We’ are talking only about negative experiences ? … I’m not
convinced. I would call it ‘realistic feedback’ … and most of it
has a real and hard background in our day by day business as
software developers.

And from an European point of view … honest feedback is better
than polite silence.


Armin I don’t know you but I would guess you are a dangerous human
being for the next generation to come.

Mario, have you ever been in Europe?

Even if you can’t imagine, in most European countries are a lot of
discussions how to save the environment etc. and the results are
new rules, recycling systems etc. since years! Reducing CO2 pollution is
taken very seriously!!!

You own a car

… but our cars need less than 10 litres per 100 Km !

or take the bus, you probably use electricity generated from buring
fuel or coal.

Hmm… solar energy and wind energy - e.g. with PROFIBUS-DP and QNX in
the plants are very popular here! There are installed a lot of
plants in the meantime and it will be installed more in the future. It’s
a quite new industry… not only discussions about alternative energy !

BTW, saving energy in houses is quite normal here. All heatings are
controlled one time per year! If you have an old house, you can get
subsidize from government for windows or other changes in the building
which save energy.

Do you think people with solar energy cells on Californian roofs would
be very happy today ??

Intelligent air condition systems also could save much energy!
Especially such energy consumpting air conditions like in N.A. are
completely unknown here

You throw chemical like paint in the sewer.

Ah, we don’t live that dangerous
… and we have hard rules, too.

We have special recycling systems, even in the deepest province. Garbage
collection in 4 systems is taken for granted: for normal waste (grey),
paper (blue), biodegradable garbage (brown) and PVC, metal, aluminium
(yellow). Container for white, green and brown glass are to find on many
corners as well at parking lots of super markets. 6 times a year are
collected rests of paints, neon light bulbs etc. Old medicine must be
given for correct recycling to drug stores. Old oil from cars is to
bring back to the petrol station. You have to pay much money if oil is
not recycled correctly! For batteries, and a lot of others we have
special recycling systems, too. It works

You probably use soap with phosphore in it?

interesting… phosphates are reduced to a minimum and here are a lot of
water saving systems. No dishwasher or washing mashine w/o intelligent
water saving system… and e.g. I don’t know any European who moved to
N.A. or lived there for a couple of month and didn’t complain about the
crazy washing mashines … too much water, too much energy and less
intelligent programs for treating the laundry with care… !

You flush the toilet every time you use it.

Hey, even there are water saving systems and you can get systems here
where the toilet is flushes with rain water!

You leave some of you computer/screen on at night.

you are wrong

They don’t know it but my kids should be afraid of you, very
afraid.

What about holidays in Germany with your kids?

Forget all what’s normal in America reg. wasting energy, water etc. and
throwing away chemical stuff as well as CO2 pollution.

Should be interesting for you and your kids to see that saving the
environment and energy has high priority … wouldn’t this be an
interesting perspective for your kids?

I hope you appreciate honest feedback and will make the best of it to
improve who you are. I’m just trying to get in the European spirit.

Would be nice to see more European spirit in America

Cheers,
Jutta

[Mario_Charest1]

“Frank Kolnick” <fkolnick@sentex.net> wrote in message
news:966jnc$ag6$1@inn.qnx.com…

I hate to see threads – especially QNX threads – take this direction.

You are right. I’m sorry. Reading other’s people respond to my post
I can see it obviously wasn’t interpreted the way I was hoping it would,
(people that know me know I don’t make personal attack). At
any rate I’ll follow your suggestion Frank and stop this thread right
here without further explanation.

Sure, Armin comes across as ‘gruff’ sometimes, but that’s a hard thing to
control in print. And I think he has a point. Any evaluation should be
balanced, and it’s much better to be aware of the limitations of any
product
before you encounter them. This forum attracts actual developpers with a
wide range of real experience – good and bad – and I certainly wouldn’t
like to miss out on that. QNX is an ideal o/s, from many points of view,
but I haven’t heard anything about dropping development or tech. support
yet

[Obviously, diplomacy isn’t my forte either, but I had to get my 2
pfennings
in.]


“Mario Charest” <mcharest@void_zinformatic.com> wrote in message
news:Ecxh6.920$> Iu3.4360@weber.videotron.net> …

“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A852324.CE7C68E0@web_.de…


“Steve Munnings, Corman Technologies” wrote:

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote in message
news:> 3A845208.78C6D481@motorola.com> …
Oh man! You take your passion seriously, don’t you?
I suddently feel an urge to post some negative experiences >
Somebody hold me, don’t let me do it!


He is posting from the viewpoint of an architectural overview of the
system.
I agree with his take on it’s inherent superiorities!

ALL, repeat ALL, OSes will give any serious developer negative
experiences - just about all the time!
The complication of the systems is just so great that it is almost
inevitable.

But nobody { well, except maybe you, Igor, and maybe Armin, and a
whole
bunch of other guys 8-} really wants to dwell on the negative
experiences.

‘We’ are talking only about negative experiences ? … I’m not
convinced. I would call it ‘realistic feedback’ … and most of it
has a real and hard background in our day by day business as
software developers.

And from an European point of view … honest feedback is better
than polite silence.


Armin I don’t know you but I would guess you are a dangerous human
being for the next generation to come. You own a car or take the bus,
you
probably use
electricity generated from buring fuel or coal. You throw chemical
like paint in the sewer. You probably use soap with phosphore in it?
You flush the toilet every time you use it. You leave some of you
computer/screen
on at night. They don’t know it but my kids should be afraid of you,
very
afraid.

I hope you appreciate honest feedback and will make the best of it to
improve who you are. I’m just trying to get in the European spirit.


Well … sometimes it is realy hard to make positive statements.
For instance: when I try to talk about my positive experiences with
XFree86, how easy it is to port X apps to QNX6 … and how stable
DDD works with XFree86 … or how powerful Qt would be on top of
Photon (what ever it means …) I had here endless debates >
Life is hard … you know >

However … from an architectural point of view, QNX 6 is a very
promising RTOS … it is much better than QNX 4, IMHO.

Armin
\

[Steve_Munnings_Corma]

Armin Steinhoff <A-Steinhoff@web_.de> wrote in message
news:3A852324.CE7C68E0@web_.de…

“Steve Munnings, Corman Technologies” wrote:

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote in message
news:> 3A845208.78C6D481@motorola.com> …
Oh man! You take your passion seriously, don’t you?
I suddently feel an urge to post some negative experiences >
Somebody hold me, don’t let me do it!


He is posting from the viewpoint of an architectural overview of the
system.
I agree with his take on it’s inherent superiorities!

ALL, repeat ALL, OSes will give any serious developer negative
experiences - just about all the time!
The complication of the systems is just so great that it is almost
inevitable.

But nobody { well, except maybe you, Igor, and maybe Armin, and a whole
bunch of other guys 8-} really wants to dwell on the negative
experiences.

Please note this ^^^

‘We’ are talking only about negative experiences ? … I’m not
convinced. I would call it ‘realistic feedback’ … and most of it
has a real and hard background in our day by day business as
software developers.

And from an European point of view … honest feedback is better
than polite silence.

Well … sometimes it is realy hard to make positive statements.
For instance: when I try to talk about my positive experiences with
XFree86, how easy it is to port X apps to QNX6 … and how stable
DDD works with XFree86 … or how powerful Qt would be on top of
Photon (what ever it means …) I had here endless debates >
Life is hard … you know >

However … from an architectural point of view, QNX 6 is a very
promising RTOS … it is much better than QNX 4, IMHO.

Armin

Oy vey! I did not try to start a flame war, honest!!
That statement had a smiley at the end - sorta like kidding, a joke, not a
serious statement!

Honestly, Armin, I appreciate your point of view, even though I do not
always agree. Please keep posting!
I also see in you the same tendencies I have in myself - argue through
something to a conclusion… (it is not all a bad thing, either)

I am sorry that I started something… I didn’t really mean that all those
people want to dwell on negative experiences, just that it sometimes seems
that way when you read the newsgroups!

Come on guys, kiss and make up!

[Igor_Kovalenko2]

Jutta Steinhoff wrote:

You own a car

… but our cars need less than 10 litres per 100 Km !

Keep in mind Jutta, here they have invented 2 things to masquerade fuel
consumption. First, they measure gasoline in gallons (3.8 liter) and
distance in miles. And gallon here costs so far just about as liter in
Europe. Second, they measure fuel consumption in ‘number of miles you
can drive on 1 gallon’, instead of ‘number of gallons you needs to burn
to drive 100 miles’. Which means you have hard time to compare.

Ok, Nissan Maxima 2000 (new 3.0 liter engine with highly improved fuel
efficiency) can do about 20 miles/gallon in city. BMW 730 (3.0 liter
manual trans) 1988 (yes 12 years old) I had in Russia used to take about
12 liter/100 km (measured by the on-board computer), which is about 20
miles/gallon. You see, japaneese cars are catching up

I have to check american cars yet…

interesting… phosphates are reduced to a minimum and here are a lot of
water saving systems. No dishwasher or washing mashine w/o intelligent
water saving system… and e.g. I don’t know any European who moved to
N.A. or lived there for a couple of month and didn’t complain about the
crazy washing mashines … too much water, too much energy and less
intelligent programs for treating the laundry with care… !

Hehe, tell me about that. This is because an american house usually
comes with all appliances installed (unless new) and they tend to be
as cheap as possible. Then people think ‘well I have washer machine
already, why bother…’. They don’t have combined washer/dryers here and
pair of front-loading washer with matching dryer would cost around
$1200, which is about twice as much as a combined one costs in Europe.

I have ordered mine from Italy for $900 after wasting some clothes in
the huge blender which they call ‘washer machine’. By the way, some
counties and states (not mine though) do send you a rebate of up to
$300 if you buy one because of energy and water savings they provide.
Now the trouble is, you can’t buy low-subsiding detergents which it
needs in a regular store. They just have no idea what the heck is that.
Damn, it was not a problem even in Russia

Some other odd things, in no particular order:

• You can’t buy Mon Cheri candies here either, which is even worse
• All instant coffee is called ‘Taster’s Choice’ like tasters all have
  one taste.
• Coffee in all restaurants appears to be coming from some special
  plumbing system, like hot water. Uniformly horrendous taste everywhere.
  When they ask ‘what kind of coffee would you like’ this means ‘the only
  one we have which is the same as everyone else have or that same but
  decaffeinated’.
• When you ask for water in a restaurant, they bring you water from
  plumbing system either. You can’t get mineral water except for very few
  places and for high price. If you ask for ‘mineral water’ they won’t
  understand, you have to say ‘Perrier’. If you ask for ‘water without
  ice’ they won’t understand either, you have to say ‘water no ice’.
• Can’t get Fanta anywhere for some weird reason.
• Absolutely all pancakes have such a high concentration of sodium that
  you can’t really eat them without causing some sort of chemical reaction
  in your stomach. And they call themselves ‘International House Of
  Pancakes’.
• They eat in movie theaters. Not to mention what they eat there…
• All european women I know here also complain about not being able to
  find any good shoes or pantyhose (which is because most women here
  wear jeans and sport shoes) and they have to go to ‘junior’ section to
  find their size
• You can’t swim in a lake after park is closed. Police won’t even let
  you get near a lake. How do they swim under the moon here for God sake?

Should be interesting for you and your kids to see that saving the
environment and energy has high priority … wouldn’t this be an
interesting perspective for your kids?

Would be nice to see more European spirit in America >

That would take moving more europeans here, rather than sending
americans to Europe

Cheers,

• Igor ‘I really miss Europe every so often’ Kovalenko

[John_Wall]

Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:
: Jutta Steinhoff wrote:
:>
:> > You own a car
:>
:> … but our cars need less than 10 litres per 100 Km !
:>

: Keep in mind Jutta, here they have invented 2 things to masquerade fuel
: consumption. First, they measure gasoline in gallons (3.8 liter) and
: distance in miles. And gallon here costs so far just about as liter in
: Europe. Second, they measure fuel consumption in ‘number of miles you
: can drive on 1 gallon’, instead of ‘number of gallons you needs to burn
: to drive 100 miles’. Which means you have hard time to compare.

: Ok, Nissan Maxima 2000 (new 3.0 liter engine with highly improved fuel
: efficiency) can do about 20 miles/gallon in city. BMW 730 (3.0 liter
: manual trans) 1988 (yes 12 years old) I had in Russia used to take about

This is not a fair or good comparison. First, the Maxima’s engine is
not new. The VQ engine has been around for a least 12 years. Second,
the 2000+ maxima’s engine produces close to 230HP, something the older
BWM engine cannot touch. Got to compare apples to apples…

By the way, the newest BWM 330i has the following
numbers:

225HP
19/27 MPG (city/highway)
auto


The Maxima AE

227HP
19/26 MPG
auto

I don’t think the japanese have any ground to make up.



: 12 liter/100 km (measured by the on-board computer), which is about 20
: miles/gallon. You see, japaneese cars are catching up

: I have to check american cars yet…

:> interesting… phosphates are reduced to a minimum and here are a lot of
:> water saving systems. No dishwasher or washing mashine w/o intelligent
:> water saving system… and e.g. I don’t know any European who moved to
:> N.A. or lived there for a couple of month and didn’t complain about the
:> crazy washing mashines … too much water, too much energy and less
:> intelligent programs for treating the laundry with care… !

: Hehe, tell me about that. This is because an american house usually
: comes with all appliances installed (unless new) and they tend to be
: as cheap as possible. Then people think ‘well I have washer machine
: already, why bother…’. They don’t have combined washer/dryers here and
: pair of front-loading washer with matching dryer would cost around
: $1200, which is about twice as much as a combined one costs in Europe.

: I have ordered mine from Italy for $900 after wasting some clothes in
: the huge blender which they call ‘washer machine’. By the way, some
: counties and states (not mine though) do send you a rebate of up to
: $300 if you buy one because of energy and water savings they provide.
: Now the trouble is, you can’t buy low-subsiding detergents which it
: needs in a regular store. They just have no idea what the heck is that.
: Damn, it was not a problem even in Russia

: Some other odd things, in no particular order:

: - You can’t buy Mon Cheri candies here either, which is even worse
: - All instant coffee is called ‘Taster’s Choice’ like tasters all have
: one taste.
: - Coffee in all restaurants appears to be coming from some special
: plumbing system, like hot water. Uniformly horrendous taste everywhere.
: When they ask ‘what kind of coffee would you like’ this means ‘the only
: one we have which is the same as everyone else have or that same but
: decaffeinated’.
: - When you ask for water in a restaurant, they bring you water from
: plumbing system either. You can’t get mineral water except for very few
: places and for high price. If you ask for ‘mineral water’ they won’t
: understand, you have to say ‘Perrier’. If you ask for ‘water without
: ice’ they won’t understand either, you have to say ‘water no ice’.
: - Can’t get Fanta anywhere for some weird reason.
: - Absolutely all pancakes have such a high concentration of sodium that
: you can’t really eat them without causing some sort of chemical reaction
: in your stomach. And they call themselves ‘International House Of
: Pancakes’.
: - They eat in movie theaters. Not to mention what they eat there…
: - All european women I know here also complain about not being able to
: find any good shoes or pantyhose (which is because most women here
: wear jeans and sport shoes) and they have to go to ‘junior’ section to
: find their size
: - You can’t swim in a lake after park is closed. Police won’t even let
: you get near a lake. How do they swim under the moon here for God sake?

:> Should be interesting for you and your kids to see that saving the
:> environment and energy has high priority … wouldn’t this be an
:> interesting perspective for your kids?
:>
:> Would be nice to see more European spirit in America
:>

: That would take moving more europeans here, rather than sending
: americans to Europe

: Cheers,
: - Igor ‘I really miss Europe every so often’ Kovalenko

–
John Wall
QSSL
Custom Engineering Group (R&D)

[Igor_Kovalenko2]

John Wall wrote:

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:

This is not a fair or good comparison. First, the Maxima’s engine is
not new. The VQ engine has been around for a least 12 years. Second,
the 2000+ maxima’s engine produces close to 230HP, something the older
BWM engine cannot touch.

So what is different about 2000+ model is the engine is not new? The pre
2000 models had worse fuel efficiency and less horsepower.

Got to compare apples to apples…

Indeed. I could have compared older BMW to older Datsun
I think you could agree on fact that cars for NA market generally have
bigger engine (which means higher fuel consumption). And they have lower
engine_volume/horsepower ratio than europeans since there’s not much
demand for more horsepower anyway.

That is understandable since there is a lot of highway driving here
and you need bigger engine to be able to accelerate fast enough to merge
into 75Mph highway from 35Mph street. Plus, americans like everything
big, that applies to cars as well as washer machines

• igor

[Jutta_Steinhoff1]

Igor Kovalenko wrote:

Jutta Steinhoff wrote:

You own a car

… but our cars need less than 10 litres per 100 Km !


Keep in mind Jutta, here they have invented 2 things to masquerade fuel
consumption. …

Yes, Igor, I know it, but worst of all is that nobody cares about CO2
pollution, feeling not responsible for next generations. Price is not so
important, but what I’m missing is any responsibility for environment
etc.

I have to check american cars yet…

tell me your result

… e.g. I don’t know any European who moved to
N.A. or lived there for a couple of month and didn’t complain about the
crazy washing mashines … too much water, too much energy and less
intelligent programs for treating the laundry with care… !

Hehe, tell me about that. This is because an american house usually
comes with all appliances installed (unless new) and they tend to be
as cheap as possible.

… and often the houses itselves are also as cheap as possible what
means pre-programmed wasting of energy…

I have ordered mine from Italy for $900 after wasting some clothes in
the huge blender which they call ‘washer machine’.

congratulation! A little bit “Europe” in your house

By the way, some
counties and states (not mine though) do send you a rebate of up to
$300 if you buy one because of energy and water savings they provide.
Now the trouble is, you can’t buy low-subsiding detergents which it
needs in a regular store. They just have no idea what the heck is that.
Damn, it was not a problem even in Russia >

Europe is “far away” and as long as they are convienced that all they
do is the “greatest” they have no chance to open their eyes…

Some other odd things, in no particular order:

• You can’t buy Mon Cheri candies here either, which is even worse >

Hey, just today I’ve bought Mon Cheri for N.A. guys I will meet
tomorrow. I’m sure there would be a big market for Mon Cheri in N.A., I
think it’s the only products from Ferrero which is not imported…

• All instant coffee is called ‘Taster’s Choice’ like tasters all have
  one taste.

I take often instant coffee with me to give American coffee a
“coffee taste”

• When you ask for water in a restaurant, …

I was always amazed, too

• Can’t get Fanta anywhere for some weird reason.

… but diet drinks with coulor and aroma… and these nice drinks even
lead to cross reactions with different medicaments… (

• Absolutely all pancakes have such a high concentration of sodium that
  you can’t really eat them without causing some sort of chemical reaction
  in your stomach.

Hmm… happy that I never tried pancakes

• They eat in movie theaters. Not to mention what they eat there…

Believe it or not, I found one as rarity here. It was in Laboe,
near by Kiel… It was so funny that we didn’t watch the movie

• All european women I know here also complain about not being able to
  find any good shoes or pantyhose (which is because most women here
  wear jeans and sport shoes) and they have to go to ‘junior’ section to
  find their size >

You will find some shops with European shoes round the corner in
Chicago… but don’t have a look to the prices… the same brands cost
3 times more than here. So you should buy shoes on your next Europe
trip.

• You can’t swim in a lake after park is closed. Police won’t even let
  you get near a lake. How do they swim under the moon here for God sake?

Should be interesting for you and your kids to see that saving the
environment and energy has high priority … wouldn’t this be an
interesting perspective for your kids?

Would be nice to see more European spirit in America >


That would take moving more europeans here, rather than sending
americans to Europe >

May be a student’s exchange program would be interesting but learning
European languages could be a problem… How many Americans do you know
who learned at least 2 foreign languages?

Cheers,

• Igor ‘I really miss Europe every so often’ Kovalenko

and for sure, the European spirit, too

Greetings from the old Europe,
Jutta

P.S.
just some feedback to RTOSes in Europe …
the European QNX market is growing