Just a reality check :)

> Hi,
> 
> >  - fully pre-emptive single kernel 
> No kernel can be *fully* pre-emptive. When it needs to fiddle around with the 
> MMU, it cannot be pre-empted. The question is, how much latency it can mean in
>  Linux. Surely more than in QNX...

Why should it be  more? The kernel isn't split into process manager and micro kernel.

> > ...with 99 real-time priorities
> We have 255! We are better, yieppie! ;-)
> 
> >  - interrupt latency in the range of 12us  (IRQ->ISR->IR-thread)
> On which hardware?

Dual-core, 1.8GHz

> A fast x86? I believe QNX is many times faster...

Seems not to be the case. For instance the non real-time 2.6.31 kernel is able to handle 1000 CAN frames/sec without 
loosing a single frame.

> >  - SMP support
> QNX has it for 10 years...

Linux has SMP since 14 years :)

> >  - multi-core support (CPU shield e.g)
> What's CPU shield?

e.g http://www.cyberciti.biz/tips/setting-processor-affinity-certain-task-or-process.html

> >  - high resolution timing for all timing services (non polling timer 
> services)
> Yeah that's something QNX should have, too. I guess they are using some extra 
> timer that today's hardware is providing...

Yes, its's available for Linux since years!
 It's part of the POSIX 1003.1b Section 14 (Clocks and Timers) API. 

> >  - huge offering of graphical interfaces (hardware/software)
> Most of them are GPL-contaminated. Once you link with it, you are obliged to 
> open-source your code.

That's not the case at user level ... GPL contamination is possible at driver level, but there is the UIO interface.

> >  - performance of the unaccelerated video interface 4 times better than the 
> 
> > performance of Photon 
> How did you measure it? What was the graphics driver on the QNX side? The 
> software-only rendering surely isn't very fast. Also remember, that QNX is 
> compiled to be compatible even with 486's. No use of MMX, etc.
> 
> >  - huge offering of applications
> Most are in pkgsrc, for QNX, aswell.

Most are X11 based ... that means not very useful.

> >  - the end user doesn't have to fiddle around with a "real-time kit" ... 
> just 
> > boot into real-time
> Just boot into real-time? Not understanding what all those processes that are 
> started there really do? That means having no control and no idea what is 
> going on when something doesn't behave as it should...

Booting into real-time is just a boot option with e.g. SUSE 11.1 

> All the so-called Real Time Linux solutions look nice on paper but as soon as 
> you try to do something with them, you begin to hate'em... ;-) (says the QNX 
> guy ;-))

Yes, I dislike the dual-kernel approach. The PREEMPT_RT version (single kernel) is perfect :)
You should check it out !

> Also, we have the better tools,

Eclipse and a lot of other tools are available for LINUX.

>  the better OS architecture,

what is better or not better depends on the requirements.

> and better Services! 

The service would be better if QSS would care about version conflicts between releases.
A run-time kit was available for QNX 6.3.2 ... has been dropped for 6.4 ... and will be available again for 6.5? That's 
some kind o Zick-Zack service :)

>And we protect the IP of the customer...

Yes, that's very easy :)

--Armin