Good bye QNX?

[Elmi]

OK, the topic is a bit pathetic for my posting - but only a bit. The “progress” that can be noticed with QNX since 6.3.x is something that is not very impressive, it lost features and did not get amazing new ones for them:

• The native Momentics IDE for QNX was dropped, now there is no real, native IDE available. Yes, Momentics can be used on Linux and Windows but cross-compilation is never as smooth as direct development.

• The software packaging system has gone. Yes, I know, there is PKGSRC available now but this is more a pain than an improvement. Very much of the PKGSRC projects do not fit to QNX because they never have been ported, they work only on *BSD. Compiling the few ones that would work on QNX often needs manual help - the URLs where PKGSRC tries to download the sources are outdated and do not work, so you have to search for the packages, download them manually and put them into the correct directory.

• The major toolkits Qt and wxWidgets are still not available for QNX, but more than this, also the X-Photon server has gone so that there is no chance to get them working. Some weeks ago I’ve been in contact with the people from openapc.com who provide a very nice and platform independent automation and visalization tool. They told me that they put huge efforts in porting their application to QNX but finally dropped that project disappointed - because the hurdles from the system are much too big

• Stupid standard hardware is not supported on QNX. Here I’m NOT talking about desktop systems but about plain, embedded Atom-boards: you have nearly no chance to get QNX running there, also QNX 6.5 fails. In 2008 QSS announced support for the Atom ( qnx.com/news/pr_3031_1.html ) but it is still unusable. May be they forgot that the Atom always requires a chipset that has to be supported too?

• The documentation of the system sometimes is lousy (see my posting about WLAN: the hardware database tells us there is support for WLAN devices but there is nothing documented about how to access it on a lower level)

So I don’t know where QNX is going to, but I afraid at the moment they only focus on some big companies like Audi and forget the hundreds of small companies that use this system too - or at least try to.

In my optinion this way is dangerous and I personally do not see any reason to use QNX again in new projects - Linux does the same job much better. Also the realtime capabilities are no longer a real argument pro-QNX, the standard capabilites of the current kernels are quite smart and the Linux realtime extensions that are available optionally can do the remainding. So the only advantage I can see at the moment is the microkernel - beside very much disadvantages.

[Thunderblade]

Hm, interesting posting, I quite can’t agree to. In my experience:

• QNX-hosted IDE was only used by very, very few people. Most people I know use Windows hosted IDE.

• Package Filesystem was quite awkward, very slow, and outdated. pkgsrc is much better.

• QT on QNX is available (just search for ‘QT QNX’ on YouTube to see a demo). Also there is Photon and finally there is even Flash and OpenGL ES. It’s such a rich choice that I don’t see your issue. What do you want with the X-Photon server? The only reason for wanting it would be porting existing GUIs from Linux - why would someone do that for an Embedded project? Re-Creating the GUI with PhAB often is much simpler and done in a few days. Except if you have very complex X-based app… I wouldn’t port it, but rather go for a hypervisor and reserve 1-2 cores for QNX.

• I never have seen an Atom board where QNX doesn’t work. Kontron, Lippert, Radisys Embedded boards are directly supported by QNX, and many others, too, work. What was the response of QNX folks you asked about this?

• As for documentation, QNX is IMHO the best documented OS in the world, all low level APIs and utilities are documented, this is not true for Linux. As for the WLAN, again, didn’t someone from QNX help you with this?

I have to admit though, that I haven’t used Linux for any real project, yet, so I am very much interested in hearing about how it does the same job much better. Also, which Linux? When ever I try to research Linux, I find that there are so many distributions, variations, and flavours that I quickly get confused (Montavista, Wind River, Freescale, etc.) Also I think the tools of QNX are much better, like Memory Analysis and especially System Profiler. And the OS is much easier to understand, and it’s much smaller.

[ingraham]

@Elmi

The native Momentics IDE for QNX was dropped

I didn’t know this. It’s disappointing. When we got into QNX 6.x, you could get an version without the IDE and some other features, at roughly half the price. We did. I ended up writing a text editor (swedit.sourceforge.net/, if you’re interested) as a result. I always missed having a decent debugger in 6.x.

@Elmi

The software packaging system has gone.

Thank god. The package file system was an atrocity.

@Elmi

Yes, I know, there is PKGSRC available now but this is more a pain than an improvement.

I don’t think it’s quite as bleak as you make it out to me. 3700 packages available as binaries. True, some don’t like to compile nicely, but there’s a lot of useful stuff in there that beats trying to port from scratch.

@Elmi

The major toolkits Qt and wxWidgets are still not available for QNX, but more than this, also the X-Photon server has gone so that there is no chance to get them working.

Don’t forget GTK. This is another disappointing one. When we switched from 4.2x to 6.x QNX actually pitched X-Photon as a distinct advantage, and touted the ability to use nedit and ddd. Gone now.

@Elmi

Stupid standard hardware is not supported on QNX.

I’ve found 6.x to work on a lot of different hardware. Then again, I’m not trying anything really crazy, and all my boards have a BIOS.

@Elmi

The documentation of the system sometimes is lousy

Sometimes. But at times it’s also quite good. I’ll take it over Linux documentation, that’s for sure.

@Elmi

So I don’t know where QNX is going to, but I afraid at the moment they only focus on some big companies like Audi and forget the hundreds of small companies that use this system too - or at least try to.

We’ve certainly gotten that same feeling.

@Elmi

I personally do not see any reason to use QNX again in new projects

It’s still a very powerful, easy to work with system. And message passing is tough to beat.

@Elmi

Linux does the same job much better.

I don’t know about better. There are advantages and disadvantages.

@Elmi

Also the realtime capabilities are no longer a real argument pro-QNX, the standard capabilites of the current kernels are quite smart and the Linux realtime extensions that are available optionally can do the remainding.

This is probably true in a large number of cases, and almost certainly true in the projects that I do. But there are some corner cases that I wouldn’t trust Linux to. (Nuclear power plant, anyone?)

My company moved away from a QNX-based solution to an off-the-shelf PLC. This was mainly due to marketing. We lost some features, but we also lost a lot of headaches. I still have a soft-spot for QNX, and I still prefer writing in C/C++ to ladder logic, but oh well.

-James Ingraham
Sage Automation, Inc.

[mario]

I don`t agree either, to be honest, you lost me when you said the documentation “sometimes is lousy”.

[maschoen]

@Elmi

…The “progress” that can be noticed with QNX since 6.3.x is something that is not very impressive, it lost features and did not get amazing new ones for them:

When I read a posting like this, I always wonder where the motivation is coming from. If QNX is so bad and Linux is so much better, why are you using QNX? I have plenty of disappointments with QNX, but I don’t package them all up into a rant that sounds like I’d like the company and product to disappear off the face of the earth. Either that or they should hire me as the CEO so I can get them to do what I want.

• The native Momentics IDE for QNX was dropped, now there is no real, native IDE available.

I have very mixed feelings about this. The problem I see is that the Java VM was crumby. I don’t know what the politics are, I once heard a rumor that Gordon thought Sun was more evil than MicroSoft, but I don’t really know why there is no Sun Java for QNX. In any case the QNX based IDE was a dog. I have a problem with such a major development component not being self hosted. On the other hand, I don’t like the IDE particularly. I’m more of a Makefile kind of guy. As I said, very mixed feelings.

• The software packaging system has gone.

Yes, good riddance.

Yes, I know, there is PKGSRC available now but this is more a pain than an improvement. Very much of the PKGSRC projects do not fit to QNX because they never have been ported, they work only on *BSD. Compiling the few ones that would work on QNX often needs manual help - the URLs where PKGSRC tries to download the sources are outdated and do not work, so you have to search for the packages, download them manually and put them into the correct directory.

I don’t know why you are mentioning pkg file system and PKGSRC in the same breath. What do they have to do with each other? You are right that PKGSRC is not magic. I did manage to get PHP/Apache 2.2 up and running with it in less than a day. Compared to what came before this was monumentally fast. I don’t think QNX ever intended to have their employees port every one of the thousands of packages. This was meant as a QNX supported community project. I don’t know how well this has worked out, but I’m a lot happier with it than without.

• Stupid standard hardware is not supported on QNX.

I’ve run into this, but this has always been a mixed bag. Ironically, a few weeks ago I was rummaging through the Gigabit hardware boards at Fry’s looking for something that QNX supported. I couldn’t find any of the chips listed in their database but I took a chance with a $10 card, and amazingly it worked.

Here I’m NOT talking about desktop systems but about plain, embedded Atom-boards: you have nearly no chance to get QNX running there, also QNX 6.5 fails. In 2008 QSS announced support for the Atom ( qnx.com/news/pr_3031_1.html ) but it is still unusable. May be they forgot that the Atom always requires a chipset that has to be supported too?

Well I don’t have a lot of experience here. I’ve worked with ADI on their Cin-Bay board. It worked off the shelf with 6.4. Fastboot is working and should be available to the public within the next few months. I see that APIC is also now supported. I don’t know what you mean by unusable.

• The documentation of the system sometimes is lousy (see my posting about WLAN: the hardware database tells us there is support for WLAN devices but there is nothing documented about how to access it on a lower level)

You see. I think we all could agree that WLAN fits nicely into the “stupid standard …” mold. I rather like the way the help system keeps my paper manuals on the shelf looking nice and new. I’d like it to be able to search on more than a single string, but maybe that will come in time.

So I don’t know where QNX is going to, but I afraid at the moment they only focus on some big companies like Audi and forget the hundreds of small companies that use this system too - or at least try to.

Valid to a point. As Willie Sutton once said, “I rob banks because that’s where the money is”. The company direction is one thing. I’ve always found the tech employees trying their best to help us small guys.

In my opinion this way is dangerous and I personally do not see any reason to use QNX again in new projects

THEN DON’T!

see, that was easy.

[Elmi]

Hi @ all and thanks for the feedback.

The answers to my two points that blame QNX for dropping the IDE/JVM and the packaging system are interesting: Nearly all of you agree that both have been of lousy quality. I agree with you too but not with the consequence: when something has a poor quality it has to be IMPROVED not DROPPED! Especially a working packaging system is something that all serious operating systems offer. At the moment also Windows is better here than QNX: most software installer systems do not remove the installed software completely and leave some trash on the system - but that is even better than QNX where no conecpt exists for removing installed software.

@Thunderblade

I have to admit though, that I haven’t used Linux for any real project, yet, so I am very much interested in hearing about how it does the same job much better. Also, which Linux? When ever I try to research Linux, I find that there are so many distributions, variations, and flavours that I quickly get confused.

It is relatively simple: all of them are Linux, all of them have the same core features and functionality and when you have an embedded system you in most case will strip down the system manually to the core features you need. And at this point it doesn’t matters if a distribution would have nice graphical tools for system management/web browsing/3D/whatever.

So you only have to decide the following:

• do you have a really slim and weak hardware then take one of the very small distributions like uCLinux (and there aren’t so much specialized distributions for this purpose)
• do you want to have good support for other processors like x86 or PPC then take Debian
• when size and computing power is not a problem take whatever distribution you like personally

@maschoen

When I read a posting like this, I always wonder where the motivation is coming from. If QNX is so bad and Linux is so much better, why are you using QNX?

To make it short: this decision was made in the past when QNX really was a better solution than Linux. That seems to have changed now - and as longer QSS follows its current path as more it worths for our company to pay the money for moving to an other system.

[Thunderblade]

@Elmi

I agree with you too but not with the consequence: when something has a poor quality it has to be IMPROVED not DROPPED!

The self-hosted IDE wasn’t dropped because it was of poor quality. It was dropped because to improve it, to reach a good quality, would have been far more work than it would have been worth.

Software companies earn money by selling software. Developing software is a lot of work. If you sell it only 1 time, you make big loss. If you sell it only 100 times you make loss. If you sell it 1000 times, you slowly reach profitable region. Of course this all depends on size of software, but Neutrino-hosted IDE is BIG.

Finally, I would like to ask you one question. You mention ‘small companies’. How many QNX development seats did your company buy? One? Two? See, there you go. Why should QNX, or any other company, care? And, if you bought one development seat, how many people are using it? One? Or more?

You know, there are people who abuse QNX’s trust and use one licensed development seat multiple times. This is a big loss of money for QNX. And to be honest, I believe they even welcome if those kind of cheaters go use some other OS. I don’t say that you belong into this group, just what I’ve seen happening in the world.

The folks at QNX are fair business people - they develop software and want their work paid. Linux, on the other hand, is a cross-financed beast, indirectly paid by lots of stakeholders. For a honest company that has a 1:1 mapping of cost vs. what they sell, with no chance of indirectly fund development and subsidize pricing, it’s difficult to compete sometimes. QNX is doing an awesome job here.

[Elmi]

@Thunderblade

Finally, I would like to ask you one question. You mention ‘small companies’. How many QNX development seats did your company buy? One? Two? See, there you go.

That is a wrong calculation in my opinion: every development license is followed up by several runtime licenses. Here the ratio is about one development license to several hundred runtime licenses.

Runtime and development licenses depend on each other: with no development environment you do not have customers that would use and buy the runtime.

[seanb]

I don’t really understand theses pkgsrc concerns. The term ‘pkgsrc’ comes
from ‘package’ and ‘source’. The issues you seem to have with building
(which I haven’t noticed) come from the ‘source’ side which wasn’t even
available with the old package manager. If you don’t like building, use binary
packages (although more things generally build then end up as a binary
package).

And qt[34] build fine from the HEAD_650 branch. I’m running them
under native X (no Xphoton) along with firefox 3.6.3. YMMV.

The fact is that QNX isn’t on the opensource radar. If something doesn’t
work someone has to get their hands in there and fix it.

Regards

-seanb

[neoman]

People are lazy. Especially when it comes to things which take time to discover.

They don’t want to fire up the console, sign up on qnx.com, making a pkgsrc SVN checkout with this account, bootstrapping it and waiting hours to compile / install with error messages they cannot understand. Even if I’m a coder I want this assistence from my operating system or having working tools which do that for me.

seanb, it’s not about pkgsrc, it’s about a Installer. With a package tree, a list, a checkbox per program and an Install button. That’s it.

Two reasons why I started with a photon-based pkgsrc installer and a port of Xphoton for QNX 6.5 (which is running stuff like xchat and GTK applications in the current build, after hours of work). But I also sometimes feel like very demotivated. Also because there is no community. Nobody is really interested in the #qnx IRC Channel. The best QNX community is the russian one on qnx.org.ru.

And I think this system can only gain attention if there is a stable base of people interested. It was a good start to found foundry27 but it’s way too complex.

QSSL must attend people who are not into that stuff and help people get on the way.

And if it isn’t QSSL who is doing that, they should support it as far as they can. Not by releasing all the source code of QNX - this is not necessary because the system can be used completely free - but by instructing their coders and techs to form a base for a new community. Even if it takes its time.

My 2 cents,
André

[Elmi]

@seanb

And qt[34] build fine from the HEAD_650 branch.

That is exactly the point why I’m saying Qt is not supported: version 3.4 is running. According to the Qt-website it is running but limited: it does not use Photon but an own, embedded GUI. So it dos not really integrate into QNX. And version 3.4 is far away from being “new” (they have reached 4.6 meanwhile including some nice features and functionalities that are used by several applications).

And If you have a look to the documentation of more recent Qt-releases you will not find any notice about QNX, so it seems that port was a one-hit-wonder.

[Thunderblade]

youtube.com/watch?v=U05iuHL2b9M

This video shows QT 4.6 running on QNX and was posted by some QT guys!

So if you really need it, talk to them.

[seanb]

@Elmi

@seanb

And qt[34] build fine from the HEAD_650 branch.

That is exactly the point why I’m saying Qt is not supported: version 3.4 is running. According to the Qt-website it is running but limited: it does not use Photon but an own, embedded GUI. So it dos not really integrate into QNX. And version 3.4 is far away from being “new” (they have reached 4.6 meanwhile including some nice features and functionalities that are used by several applications).

And If you have a look to the documentation of more recent Qt-releases you will not find any notice about QNX, so it seems that port was a one-hit-wonder.

When I say qt[34] I mean qt3 and qt4. qt4.6.2 libs and tools build
and run for me under native X on qnx 6.5.0 so it’s a least a two
hitter. Again YMMV. I’m not saying any of this is at all easy yet but
the groundwork is in place for people to run with it.

And nothing under pkgsrc is really supported. It’s there for your pleasure.

-seanb

[flapdoodle]

We’ve had a fairly recent version of Qt running on QNX, and it ran very well. I’m new to QNX and have found, in general, the documentation is very good, and the OS has a lot of features - perhaps too many - and some bits (Such as aynch messaging) are a bit hidden. There’s sometimes three ways to do the same thing, and it’s not clear which is the best.

We’re actually using the photon GUI for an embedded system (Is this the best way?) at the moment. So far it all seems good. We couldn’t use Qt as it was unsupported.

Occasionally the documentation does get a bit frustrating in that some details are missing, and we’re currently struggling to achieve something important that Linux supported out of the box. I don’t particularly need much support, just a bit of an idea of direction, but it seems quite hard to get that… And I’m baffled as to why there is no DDK for io-pkt4…?!

[BigBear]

@Elmi

• The native Momentics IDE for QNX was dropped, now there is no real, native IDE available. Yes, Momentics can be used on Linux and Windows but cross-compilation is never as smooth as direct development.

By far most people use Windows as development environment, therefore this is not an issue.

• The software packaging system has gone. Yes, I know, there is PKGSRC available now but this is more a pain than an improvement. Very much of the PKGSRC projects do not fit to QNX because they never have been ported, they work only on *BSD. Compiling the few ones that would work on QNX often needs manual help - the URLs where PKGSRC tries to download the sources are outdated and do not work, so you have to search for the packages, download them manually and put them into the correct directory.

PKGSRC is much more flexible than the old package installer. Obviously, the handling is more complicated but QNX is not for milksops

• The major toolkits Qt and wxWidgets are still not available for QNX, but more than this, also the X-Photon server has gone so that there is no chance to get them working. Some weeks ago I’ve been in contact with the people from openapc.com who provide a very nice and platform independent automation and visalization tool. They told me that they put huge efforts in porting their application to QNX but finally dropped that project disappointed - because the hurdles from the system are much too big

Photon works very well, even for heavy-load applications. No need to switch to other systems.

• Stupid standard hardware is not supported on QNX. Here I’m NOT talking about desktop systems but about plain, embedded Atom-boards: you have nearly no chance to get QNX running there, also QNX 6.5 fails. In 2008 QSS announced support for the Atom ( qnx.com/news/pr_3031_1.html ) but it is still unusable. May be they forgot that the Atom always requires a chipset that has to be supported too?

Are you kidding?
QNX is running smoothly on Atom boards
youtube.com/watch?v=rYZ0bOndtA8

• The documentation of the system sometimes is lousy (see my posting about WLAN: the hardware database tells us there is support for WLAN devices but there is nothing documented about how to access it on a lower level)

The documentation is perfect. But it is not suited for “Copy and Paste” programmers who are used to copy code snippets from the internet into their applications.

So I don’t know where QNX is going to, but I afraid at the moment they only focus on some big companies like Audi and forget the hundreds of small companies that use this system too - or at least try to.

The companies not only try to use it but they are REALLY using it successfully.

In my optinion this way is dangerous and I personally do not see any reason to use QNX again in new projects - Linux does the same job much better. Also the realtime capabilities are no longer a real argument pro-QNX, the standard capabilites of the current kernels are quite smart and the Linux realtime extensions that are available optionally can do the remainding. So the only advantage I can see at the moment is the microkernel - beside very much disadvantages.

Please stay awy from QNX in the future if you don’t understand it and don’t waste other peoples time.

[HansHans]

@BigBear

Please stay awy from QNX in the future if you don’t understand it and don’t waste other peoples time.

I’m missing your arguments.

Simply telling somebody is wrong without giving any reasons is nothing what I would name a “professional discussion”.

[ingraham]

@BigBear

By far most people use Windows as development environment, therefore this is not an issue.

Not sure where you’re getting your data from on this. But if it’s true, why bother with QNX at all? Self-hosted development is one of the only things that QNX has that is truly unique in the RTOS world.

@BigBear

PKGSRC is much more flexible than the old package installer. Obviously, the handling is more complicated but QNX is not for milksops

The old package installer sucked, for sure. But are you actually BRAGGING about pkgsrc being difficult to use?

@BigBear

Photon works very well, even for heavy-load applications. No need to switch to other systems.

It’s not a question of switching to other systems. It’s a question of available functionality. I’ve bitterly complained for years about the lack of any kind of vector graphics support. Maybe the Khronos / OpenGL ES stuff will eventually lead to OpenVG support, which would be something. Anyway, there are an awful lot of programs out there written in Qt or GTK+ that it would be nice to be able to leverage.

@BigBear

The documentation is perfect. But it is not suited for “Copy and Paste” programmers who are used to copy code snippets from the internet into their applications.

Perfect, huh?

@BigBear

Please stay awy (sic) from QNX in the future if you don’t understand it and don’t waste other peoples time.

Well, that attitude doesn’t do much for the QNX community, does it? The guy is complaining about lack of support and you tell him not only that you won’t help him but that he never should have asked in the first place. I’m glad the other people on this forum do not share your attitude.

-James Ingraham
Sage Automation, Inc.

[TDK731]

I think that it is VERY strange that HansHans uses the same useless phrases like elmi…

[maschoen]

TDK731,

What are your rates for detective work.   You seem to be really good at it. :slight_smile:.

[BigBear]

@Elmi

The major toolkits Qt and wxWidgets are still not available for QNX

youtube.com/watch?v=U05iuHL2b9M