Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Every developer I know (myself included) that has worked with QNX has a story about some insane bug that took significant effort to uncover. At this point, I would say the only reason one should look at QNX is for cost since it is pretty cheap. The low jitter on context-switching to the highest priority thread is a nice thing but the dev process is absolute garbage.


yep. it's really trash. used it 20-25 years ago when they were just introducing "neutrino" vs. the classic QNX4. the former had a good rep with auto and medical usage.

- very bad port of GCC was buggy and generated bad code. it was the result of some idiot blindly haphazardly applying a ton random incoherent patches to try to get it to build instead of porting it properly. (to be clear mainline GCC at that time was fine; we re-ported it ourselves instead) - and, of course, they used their own faulty compiler to build their libraries and services ;) causing unknown carnage waiting to be discovered.

- malloc broken (heavy use under multiple threads causes heap corruption). replaced with dlmalloc.

- serial port driver broken. rewrote a new one.

- intel network card driver crashes. replaced hardware with 3com to survive.

- certain math library functions broken (iirc, fmod). replaced.

and so on and on.

it doesn't matter what certification your RTOS (or whatever) has. if you cannot examine the source, rebuild it, etc. (oss or private source available) - it cannot be trusted. this was one of the worse examples, but it's always like this with "proprietary" OS/toolkits.


When you can tell qnx to give you a root shell as an unprivileged user, ps being slow doesn't surprise me... https://www.juliandunn.net/2006/08/21/on-hacking-the-unisys-...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: