Christmas is already behind us, but since this is an announcement from 11 December – that I missed – I'm calling this a very interesting and surprising Christmas present.
The team and I are beyond excited to share what we've been cooking up over the last little while: a full desktop environment running on QNX 8.0, with support for self-hosted compilation! This environment both makes it easier for newly-minted QNX developers to get started with building for QNX, but it also vastly simplifies the process of porting Linux applications and libraries to QNX 8.0.
↫ John Hanam at the QNX Developer BlogWhat we have here is QNX 8.0 running the Xfce desktop environment on Wayland, a whole slew of build and development tools like clang, gcc, git, etc.), a ton of popular code editors and IDEs, a web browser (looks like GNOME Web?), access to all the ports on the QNX Open-Source Dashboard, and more. For now, it's only available as a Qemu image to run on top of Ubuntu, but the plan is to also release an x86 image in the coming months so you can run this directly on real hardware.
This isn't quite the same as the QNX of old with its unique Photon microGUI, but it's been known for a while now that Photon hasn't been actively developed in a long time and is basically abandoned. Running Xfce on Wayland is obviously a much more sensible solution, and one that's quite future-proof, too. As a certified QNX desktop enthusiast of yore, I can't wait for the x86 image to arrive so I can try this out properly.
There are downsides. This image, too, is encumbered by annoying non-commercial license requirements and sign-ups, and this also wouldn't be the first time QNX starts an enthusiast effort, only to abandon it shortly after. Buyer beware, then, but I'm cautiously optimistic.
= Related: QNX at Wikipedia
(Score: 3, Informative) by pTamok on Saturday January 03, @09:34AM
is here, for more background
https://www.phoronix.com/news/QNX-Self-Hosted-Dev-Desktop [phoronix.com]
(Score: 4, Insightful) by Anonymous Coward on Saturday January 03, @11:09AM
Its not a FOSS Photon or QNX that fits on a floppy.
It's all the frustrations of dealing with a commercial UNIX like OS (signups, email verification, license agreements, lack of freely available documentation, lack of discussion forums, etc) combined with all of the frustrations of running Xfce. In a VM.
If you are going that far, just install Solaris.
(Score: 3, Informative) by Bentonite on Sunday January 04, @07:06AM (1 child)
Therefore it should not be used and you should not start using it.
Install a real OS instead - xfce4 can quite easily be installed on GNU/Linux-libre and you'll want a real compiler - GCC, not clang.
(Score: 2) by ShovelOperator1 on Sunday January 04, @03:43PM
It's worse.
In typical proprietary software licensing model, you sign a contract with manufacturer. Especially when adapting software for a specific task, and there are manufacturing lines controlled by QNX-based systems. The contract works as both sides have their conditions and demands. But it works only if both sides stick to the rules.
QNX history is full of broken contracts. Or reinterpreted. Or something open to a nearly BSD license, then closed and then forks closed on DMCA. Or contracts broken because "f... you". Or because "sue us". It started in late 90s and went thru all 2000s, blooper after blooper. This gives QNX a really bad opinion when choosing as an application-specific system. They will have a really hard time trying to be chosen by someone who does not remember their interrupt strategy, the microkernels or the famous OS-on-a-floppy, but can open the archive scans of IT press of these times.
(Score: 2) by Rich on Sunday January 04, @04:44PM
I'd say it's more for retaining customers than an advertisement for acquiring new ones, like the browser floppy was. Customers are probably like "this cross compiling is annoying, let's switch our target to RT Linux" and this way customers can work "on-device". I can attest that it's super convenient for complex devices if you can pull out a limited main controller board and instead connect your development machine straight to the low-level controllers.
Plus, Wayland isn't really something you'd want to run on embedded target hardware, given its complex tie-in Linux GPU requirements.
I've ranted about Wayland before, but this shows that Wayland rips open a gap where just a plain framebuffer is available from the hardware and/or memory is limited to a point that generous bitmap buffering of the many layers of a GUI stack is not feasible.