Today we're happy to feature an interview by Grant Hayes of MacSlash with Paul Leroux, a technology analyst with QNX Software Systems, who is participating in Embedded World 2006. In the interview, Paul discusses the changes QSS has experienced in the last couple years, new and established competition, and moving forward in the marketplace with new technology.
Post a Comment
Member since:
2005-11-15
Member since:2005-07-06
I concur. I did some work in QNX many moons ago and was simply amazed at how easy it was to get started compared to Embedded XP (which was our previous platform). Another thing i noticed was that when using Eclipse in QNX, it was like night and day compared to using Eclipse in XP. I had to assume the JRE in XP is either really bad, or QNX's JRE was REALLY good.
Suffice to say, QNX would be my preference when doing work for embedded devices.
of course, the absolute BEST api i've ever used in my career would be BeOS's api. there's my beos injection for this thread. 
Member since:2006-02-15
If you like the BeOS API, check out "Zinzala" which was built for QNX. Although it doesn't specifically mention BeOS, I'm sure you'll find that it bears more than a passing resemblence to the Be API. There's an introduction at http://www.hexazen.com/Products/SDK/Zinzala/Articles/083004/.
Member since:2005-07-06
Member since:2005-07-06
nivenh, you could also check the following (more detailed) OSNews article:
http://www.osnews.com/story.php?news_id=9112
Edited 2006-02-16 23:14
Member since:
2005-07-13
Member since:
2006-02-15
He didn't even mention or explain why iDefense recently posted several vulnerabilities of QNX at bugtraq (all of them resulting in root-access for the attacker), because they didn't even respond in a timespan of more than one year!
It makes me feel uneasy somehow that this security-unaware company is still selling software, which could even run in my car!
Member since:2006-02-08
QNX is not really about security. Heck, if you run the remote platform debugging daemon (qconn) as a service, any code you remote debug will even run as root!
The thing about QNX is that, once you have developed it and have it embedded on a system, there is virtually no way access to the code. Unlike other *nix systems the embedded space is less about plugins and modularity, it's more about using limited power devices to achieve a specific objective.
Besdies, when's the last time you see someone take their car or their handheld GPS (not PDA GPS' like iQue btw) for upgrade?
QNX is not the OS where you run apache or use it as a Desktop machine.
Member since:2005-08-08
"QNX is not really about security"
"The thing about QNX is that, once you have developed it and have it embedded on a system, there is virtually no way access to the code."
You think someone who is defending QNX would actually RTFA.
"Who is adopting QNX Neutrino lately?
Paul Leroux: The auto market has embraced QNX Neutrino in a big way. Companies like Audi, DaimlerChrysler, Honda/Acura, Hyundai, and Saab all ship QNX-based telematics and infotainment units in their vehicles. Networking is also very strong - witness the release of Cisco's flagship, the CSR-1 routing system, which is based on our microkernel technology."
Or know anything about what they do... http://www.qnx.com/markets/networking_telecom/
http://www.qnx.com/markets/security_defense.html
Security is extremely important to QNX.
Member since:2006-02-08
Sorry I was typing too fast in my replies. Let me rephrase.
When I say QNX is not about security - I was referring to the development environment (that's why I mention the qconn case). To reply to DoubleSpeak, most of the iDefenseLab vulnerability in QNX (at least it seems to me) would affect development systems a lot more than deployed systems. I can't see people hacking around the "su" access vulnerability when all they get is touch screen in a mission critical system for example.
Deployed QNX systems are quite secure when it gets locked down. If you look at the Cisco example They say that any failure would not affect others. quote "In QNX Neutrino, virtually any software component can fail and be intelligently restarted without rebooting and without impacting other services." That's basically what I said in my prev post.
Member since:
2006-02-15
Then, they should better eliminate all networking code in QNX.
There are already some remote vulnerabilities known related to cars (i.e. related to bluetooth - "carwhisperer"; although it's no QNX-specific problem). Buggy and insecure software in cars which also provides remote access could really be a problem in the future. I just hope some kind of hacker will never get my airbag to open automatically
Member since:2006-02-08
I should be a bit more clear. Even if security is not a strongpoint in QNX, by the virtue of the microkernel many code cannot be run.
The networking code in QNX can be enabled/disabled and installed in parts. Since QNX do use a microkernel, each driver can be run with different permission/user or priority as they see fit. Even the TCP/IP stack is not part of the kernel. For example, if the bluetooth driver was crashed the worst that happens is that the bluetooth driver related subsystems (probably just the GPS and maybe phone) would get disabled. By the virtue of the kernel it can't deny other services of its dedicated timeslice. I would guess that a well-designed embedded system would have each subsystem running as a different user/group id.
One more thing going for QNX is that you can run a whole QNX embedded system without any developer tools (which is the norm when deployed) and without scripting support. Without neither hacking will be somewhat difficult.