QNX is now free for anything non-commercial, plus there's an RPi image

Overview of the Release

  • QNX 8.0 is now free for non‑commercial use, with an RPi 4 image and other BSPs.
  • Non‑commercial license is described as perpetual and self‑service, giving access to the full development suite and targets.
  • Intended audiences called out: students, hobbyists, academics, and small non‑profit projects.

Licensing Model and Trust Issues

  • Many commenters welcome a free tier but criticize:
    • Prior “rug pulls” (source available twice before, then abruptly closed).
    • A termination clause letting BlackBerry revoke licenses at any time.
    • “High‑risk application” and “societal loss” wording seen as vague and risky.
    • Requirement to sign on behalf of institutions and hardware telemetry collection.
  • Some argue only true open source (e.g., GPL/AGPL or permissive licenses) would rebuild trust; others propose an Unreal‑Engine‑style royalty model.
  • Several say they will not invest time in QNX again without a fully open license.

Technical Characteristics and Comparisons

  • QNX described as a microkernel RTOS with:
    • Message‑passing IPC tightly integrated with scheduling, priority inheritance, and network transparency.
    • User‑space drivers that can be restarted, and minimal kernel (no paging by default).
    • Strong POSIX compatibility, making many Unix CLI tools portable.
  • Praised for deterministic latency and suitability for safety‑critical and high‑availability systems (automotive, industrial, medical).
  • Comparisons:
    • Versus Linux: PREEMPT_RT now in mainline; some say that makes QNX less relevant, others argue Linux still isn’t a true hard‑real‑time OS or easily certifiable.
    • Versus FreeRTOS/Zephyr/etc.: QNX occupies a different niche (full OS with MMU, drivers, GUIs, not just a tiny executive).
    • Some suggest seL4 or other microkernels for security/verification; others note those are more minimal than QNX.

Use Cases, Relevance, and Alternatives

  • Existing deployments mentioned in cars (infotainment, instrument clusters, ADAS) and telecom/routers.
  • Some see QNX as “20 years too late” for new adoption, squeezed by Linux from above and lightweight RTOSes from below.
  • Others argue diversity beyond Linux monoculture is valuable, especially for certified safety systems.
  • Hobbyist project ideas discussed: robotics, Trilobot, weather stations, cash registers, classic games.

Developer Experience, Ecosystem, and Accessibility

  • Some praise the core developer experience (POSIX tools, CMake, microkernel design).
  • Major complaints:
    • Poor or lagging driver/BSP support vs Linux.
    • Small, aging community; few examples; “working with 25‑year‑old software”.
    • Heavy friction to try it: mandatory account, license flows, license manager, QNX Software Center just to download images.
    • Password/account system seen as outdated and restrictive.
  • Suggestions: easier downloads without accounts, VM images like Microsoft’s, bug portal, better docs, and clear positioning on “what QNX is” on the marketing site.

Desktop, UI, and Nostalgia

  • Strong nostalgia for:
    • The 1.44MB demo floppy with GUI+browser.
    • Photon microGUI and earlier desktop‑capable QNX releases.
    • Historical speed and “snappy” feel compared to contemporary OSes.
  • Photon is confirmed long‑dropped; modern QNX targets embedded/graphical systems, not general desktops, though community window managers exist.
  • Some recall earlier QNX on PDAs, the ICON school computers, and BB10/PlayBook devices, lamenting missed opportunities.