Well, size really does matter. If the base system takes up less space it leaves more resources left over for vendor value add product.
Sure linux or Windoze might fit, but not as many other goodies would.
What this adds up to is bottom line.
The bottom line is you can have a device with
less resources (memory, disk space, etc.) to do the job with QNX than with the others. So maybe this lighter hw requirement means it saves the vendor $10 per unit... ship 1,000,000 units and you can see why the choice isn't so hard.
Even for devices with identical hardware, the device built based on QNX has more features because more will fit... which product will Joe Blow buy, product A with 10 bits of goodies or QNX based product B with 20 bits of goodies for the same price?
That is why size is important. The realtime, fault tolerant, blazing speed things are just gravy for the most part:-)
How is it more friendly? Lets say you write code that extends the OS's abilities.
Option A) On QNX you write the resource manager (lets just call it that). Run it... opps, it crashed. Run resource manager in debugger, and debug it. Edit source. recompile. Run. Don't want your resource manager anymore? slay it off. make more mods, run it again... you get the idea.
Option B) On Linux. write the code. build the kernel with your mods. reboot (ick). opps, it crashed (whole OS goes bye-bye). boot using alternate image. Pull out *LOTS* of hair fixing the thing... you think. rebuild kernel, reboot (and pray). wash, rinse repeat... Ok, you got it working the way you want. Don't want to use it right now... sorry - if you are going to use the sevices that code provides it must be omni-present. The only option is to boot between two versions of the kernel... one with one without the additional services.
Option C) With QNX that piece of code is a seperate process which can be started and stopped as needed. It can also be watch dogged... if for ANY reason your resource manager (for want of a better name) terminates unexpectedly, it can be restarted and services restored quickly.
Option D) Same code built into Linux kernel... if for any reason the code terminates unexpectedly (faults) --- BOOM!
So I'm curious... which options do you think are more friendly (pick any 2);-)
For stuff that you wouldn't link into the linux kernel, what does having the kernel source buy you? A deeper understanding of its inner workings? Which you shouldn't need if the kernel just works and does what it is supposed to do right?
Part I: Sounds like a cool app. Can't wait to see the ports. Photon supports alpha, chroma, overlay scaler hardware, accelerated ops into offscreen memory, blitting between offscreen memory objects etc. all the essential components for doing snazy graphics are available... with more to come! Part II: No need to "switch" to X. Just run the X apps directly in Photon... even if they're non-ported Linux apps. The X and Photon apps co-exist quite nicely.
Qnx is used for the space vision system used to allow the operators of the arm to acurately position the objects being manipulated in three space. You don't want glitches/hicups/delays when working with a piece of equipment that would cost billions to replace. Qnx is also being used on the International Space Station. As far as Qnx being a good OS... I suppose we could ask the good folks at NASA why they went with Qnx over Linux or Be, they do have budget concerns after all. Something I've always found amusing... Qnx has had several NDA's that prevent us from revealing some of the cool applications and devices running our OS. The reason: They consider Qnx to be their primary advantage over their competition:-)
Slashdot Mirror
Well, size really does matter. If the base system takes up less space it leaves more resources left over for vendor value add product. Sure linux or Windoze might fit, but not as many other goodies would. What this adds up to is bottom line. The bottom line is you can have a device with less resources (memory, disk space, etc.) to do the job with QNX than with the others. So maybe this lighter hw requirement means it saves the vendor $10 per unit... ship 1,000,000 units and you can see why the choice isn't so hard. Even for devices with identical hardware, the device built based on QNX has more features because more will fit... which product will Joe Blow buy, product A with 10 bits of goodies or QNX based product B with 20 bits of goodies for the same price? That is why size is important. The realtime, fault tolerant, blazing speed things are just gravy for the most part :-)
How is it more friendly?
;-)
Lets say you write code that extends the OS's abilities.
Option A)
On QNX you write the resource manager (lets just call it that). Run it... opps, it crashed.
Run resource manager in debugger, and debug it.
Edit source. recompile. Run.
Don't want your resource manager anymore?
slay it off.
make more mods, run it again... you get the idea.
Option B)
On Linux. write the code. build the kernel with
your mods. reboot (ick). opps, it crashed (whole OS goes bye-bye). boot using alternate image.
Pull out *LOTS* of hair fixing the thing... you think.
rebuild kernel, reboot (and pray).
wash, rinse repeat...
Ok, you got it working the way you want. Don't want to use it right now... sorry - if you are going to use the sevices that code provides it must be omni-present. The only option is to boot between two versions of the kernel... one with one without the additional services.
Option C)
With QNX that piece of code is a seperate process which can be started and stopped as needed. It can also be watch dogged... if for ANY reason your resource manager (for want of a better name) terminates unexpectedly, it can be restarted and services restored quickly.
Option D)
Same code built into Linux kernel... if for any reason the code terminates unexpectedly (faults) --- BOOM!
So I'm curious... which options do you think are more friendly (pick any 2)
For stuff that you wouldn't link into the linux kernel, what does having the kernel source buy you? A deeper understanding of its inner workings? Which you shouldn't need if the kernel just works and does what it is supposed to do right?
Ok, I admit it -- I'm a little biased.
Part I: Sounds like a cool app. Can't wait to see the ports. Photon supports alpha, chroma, overlay scaler hardware, accelerated ops into offscreen memory, blitting between offscreen memory objects etc. all the essential components for doing snazy graphics are available... with more to come! Part II: No need to "switch" to X. Just run the X apps directly in Photon... even if they're non-ported Linux apps. The X and Photon apps co-exist quite nicely.
You mean like watch a DVD with no frame loss. Play Unreal Tournament or Quake III?
Almost par whith QNX is good I guess, but why settle?
Qnx is used for the space vision system used to allow the operators of the arm to acurately position the objects being manipulated in three space. You don't want glitches/hicups/delays when working with a piece of equipment that would cost billions to replace. Qnx is also being used on the International Space Station. As far as Qnx being a good OS... I suppose we could ask the good folks at NASA why they went with Qnx over Linux or Be, they do have budget concerns after all. Something I've always found amusing... Qnx has had several NDA's that prevent us from revealing some of the cool applications and devices running our OS. The reason: They consider Qnx to be their primary advantage over their competition :-)