Previously, Alain Bonnefoy wrote in qdn.public.qnxrtp.advocacy:
QSSL seems not be very disposed to continue the developments on XPhoton,
as QSSL don’t give any information about a future debugger, we can think
that QSSL don’t really want that QRTP continues its life as a
development platform.
What are you babbling about? The GUI of choice for QNX is Photon, the
only reason that XPhoton exists is to assist in porting applications
to QNX. I personally have not seen any of the problems that folks have
reported with XPhoton, then again, I haven’t tried to just plain run
some bizzare Xapp with it. It runs my corporate X-based tools perfectly
well, and in the case of bringing an app to QNX, well… if it has some
deficiencies, then that just helps to encourage the next phase of
porting that appliation to QNX, that of replacing the X interface with a
photon interface. Think about it, it just DOES NOT make sense to rely
on anything in X for an embedded environment does it? XPhoton issues
aside, the resources for X are simply too large. The benefits of
porting the GUI portion of an application to photon are huge.
In that perspective, QSSL is providing a very STRONG direction for the
future of development on QNX… NATIVE development, which is exactly
what they should be doing.
Put on a “business” hat, and you will quickly see that X isn’t a product
that represents any significant revenue for an embedded OS, while Photon
represents exactly that.
I had a meeting yesterday with a supplier which is going to sell us some
motherboards and other electronic cards with neutrino embedded.
They told me about many of problems with your tools to create system
images, to flash the image, …, and about their difficulties to have
the informations they need.
It seems that all these low level tools don’t work correctly. Some don’t
work at all.
This is not surprising, have you ever WORKED for an electronics
manufacturer? Their expertise is in making their hardware work, and NOT
in making every OS in the world work on it. Their test engineers
typically use DOS/Windows-based test equipment, and that is the primary
concern for a motherboard manufacturer. To get QNX working on an
embedded device requires significant training, and extensive knowledge
of QNX, this is not something that typically provides a sizable return
for the hardware manufacturer. This makes perfect sense, take someone
like Asus, they manufacture MILLIONS of PC motherboards, and I’ll go out
on a limb and guess that fewer than 1% of them ever wind up runing QNX.
The investment (to train personelle) is simple much, much larger than
the return. In fact, there is a higher chance that the personelle you
train would leave the company long before you got a return on the
investment, and then you’d literally have to start over.
With that said, it is not surprising that a manufacturer would complain
about QNX’s tools. The problem [I’ll wager] is not that the tools are
bad or broken, I think they are, but that the PEOPLE trying to use them
simply are untrained or inadequately trained to use them. Think of an
airplane, to me (an untrained & inexperience user) they seem
overwhelming, far too complex and impossible to understand and use. To
a properly trained and experienced pilot, they are not. This is the
same case.
There are a few companies, that work predominently in the embedded
market manufacturing hardware that do support QNX, and they support it
well. The one that comes to mind is Arcom (
http://www.arcomcontrols.com ). They had QNX RTP running on their
hardware in a fairly short time. How did they manage that? Well, the
most important is that Arcom has taken the time to train their engineers
on QNX (and other OSs that are popular in the embedded world). They
have sent them on the FULL training courses from QSSL, they have formed
official partnerships with QSSL, and they send those same engineers to
tradeshows. The other reason why a company like Arcom can actually
benefit from doing this is that manufacturing SBC’s is not their only
business. They also have a large business actually building and
programming embedded systems for clients, which means they can use QNX
for more than just supporting their hardware, they actually build
products that require an OS like QNX.
In the embedded world, choosing a vendor is an important step, you can
find one that is cheap, but that can offer little to no techical support
for the OS you are using. You can also select a vendor that CAN provide
that level of support and that has partnerships with your OS vendor to
work through some of the deep issues that you would never want to get
into (like making an IPL or BIOS).
I’d reccomend Arcom, go talk to them. Give Frank P. a call, tell him I
sent you, and tell him what you want/need with QNX. I know they can
help you and I know that they won’t have the issues you are complaining
about.
-+> It seems that neutrino only exists to start on a PC.
Absolutely. Again, there is only one platform that is used for
self-hosted development, and that is x86 on a desktop PC. This is not
very different than all the other RTOSs out there. The HUGE difference
is that all the other RTOSs are not self-hosted on anything, you still
have to use an x86 desktop PC for cross-compiling and downloading into
the target hardware. You have to download & reboot the target hardware
to test ANYTHING. That is NOT the case with QNX. You can develop and
test everything from an x86 desktop without even having the target
hardware. That’s a huge advantage.
Quite simply, your expectation that just because QNX can do this on x86,
that it should also do it on every board and every CPU supported is
simply unrealistic. There is no “common” hardware platform for those
other CPU’s which is why this is not possible. QNX does not make the
hardware, so this is not their fault, nor is it their responsibility.
Did you forget that Neutrino is, first, an industrial operating system,
and not a desktop system ??
No one has forgotten that, except perhaps you. You’ve just complained
that it doesn’t provide desktop services on your “industrial” hardware.
Make up your mind what you want.
What do you want now? To be on the Windows or Linux market? To leave the
embedded market?
Not at all, the self-hosted development environment runs on the same
hardware that the lion’s share of Linux developers use. That makes it
trivial for those developers to install and run QNX and learn to develop
for QNX as well. There is no desire for QNX to enter the “linux
market” (hey, it’s all “free” in that market, which doesn’t make it a
very profitable market at all, which is apparant with what is happening
to all those linux companies with the current economy). In contrast,
QSSL is going strong, and its advantages make it MORE attractive given
the current economy.
I don’t understand how many time you waste to develop so many new
functionnalities before trying to solve all existing important bugs and
missing features as name server, for example, which is a big hole in
your network transparency!!
What the hell are you talking about? QNX has the most transparent
network available in the industry today. It is mature on QNX4, and is
in beta on QNX6. I have no doubt that the official release (ie.
non-beta) of QNET will be very stable and will provide the same
transparency that we have in QNX4.
Cron, which is a system utility, and don’t work at all, is maybe more
crucial than a set of backdrops!
Cron works fine, you’re doing something wrong. RTFM, and then fix what
you are doing wrong. If there is an actual problem, then report the bug
and work with QSSL to resolve it. I’ve had years (some would say eons)
of experience working with QSSL, they are INCREDIBLY responsive, they DO
listen, and they DO fix things. Go grab an IRC client (
http://www.joher.com/phirc ) and join the #qnx channel on irc.joher.com
& irc.qnxstart.com where you will be able to talk with many QSSL
developers to help resolve your problems. At least you’ve found these
newsgroups, which is the other useful area.
We don’t care about RealPlayer, Quake, CD reader, Mpeg player until the
operating system works correctly, the network works correctly, the
graphical interface works correctly, and all other basic
functionnalities works correctly.
You are over reacting. The OS does work correctly, and unless you’ve
been living in a cave without net access, you’d also know that those
thing you mention as not required for YOUR appliation, are in large
demand for many of the new embedded devices such as game consoles,
internet appliances, PDAs, personal music systems, and such. As for
Quake, well… that’s just to give those Linux developers one less
reason to reboot back into another OS.
Of course, we will always meet some guys who want to change the Photon
look and feel but, seriously
, I think that the majority of QRTP users
will understand other priorities.
I’m convinced that QRTP (to talk about neutrino and all the components)
is a very good product. I think that everybody agrees to say that what
is done is clear and well done. We are developpers like you, and we
can’t blame you about existing bugs (If you try to solve them). But, I
have the impression that you are in a race to a maximum number of
applications, and I’ d like to say, unfortunately, often for
embelishment, what, from my point of view, damage the product.
Please help us in our developments by envolving the usefull tools, I
think it will be better for your and our success (I mean, in the long
term), than to try to smash the downloads record with embelishments.
Best regards,
Alain.
–
Martin Zimmerman camz@passageway.com
Camz Software Enterprises www.passageway.com/camz/qnx/
QNX Programming & Consulting
