Live data from Hacker News

QNX Self-Hosted Developer Desktop

devblog.qnx.com

151–160 of 174 posts

Re: QNX Self-Hosted Developer Desktop

#151
post #27

I always liked their original UI - Photon[1][2]. Very lightweight and fast. Also a distinct and consistent style. I understand why they dropped it in favor of Qt and later Web technologies, but it's still a big loss. [1] https://www.qnx.com/developers/docs/6.5.0SP1.update/com.qnx.... [2] https://www.mikecramer.com/qnx/momentics_nc_docs/photon/prog...

> I understand why they dropped [Photon] in favor of Qt and later Web technologies

The arrows of time branch and spiral, so it's possible that "later" could require some properties of "earlier".

If Photon could not be open-sourced, it could be licensed to a third party for custodian maintenance. If QNX is abandoning Photon forever, would Blackberry object to Photon being cloned for Linux or FreeBSD? That could preserve a future option for QNX to use it again, like XFCE.

Enthusiasts still use Blackberry keyboards on handheld devices in 2025, which sell out in minutes. In a parallel universe, Blackberry.com offers embedded SBC developers self-service purchase and global delivery of the legendary Blackberry keyboard, with Bluetooth for convenience or USB-c for security.

Re: QNX Self-Hosted Developer Desktop

#153
post #44

Earlier quoted context omitted.

> Should I expect backdoors? Is it an elaborate front by north korea? Who will be able to remotely execute code on this operating system? Stop sowing FUD https://en.wikipedia.org/wiki/Fear,_uncertainty,_and_doubt

You should "trust, but verify" and not shoot the messenger. If raising valid concerns that were not addressed by the linked website is FUD for you, so be it. Sourceforge was also a major brand back in the day and nowadays it raises an anti virus alarm if a user visits that website.

> If raising valid concerns that were not addressed by the linked website is FUD for you, so be it.

Yes, it is. It's specifically called concern trolling: https://en.wiktionary.org/wiki/concern_troll

In this case it's because the mass-market operating systems with which QNX could compete already do the things you're “concerned” about. QNX could only be an improvement in that regard.

Re: QNX Self-Hosted Developer Desktop

#154

A bit dissapointed by this. You have to create an account, get a license, deploy it and then you get a fucking download manager just for linux and windows to download who knows what that should run on qemu. Why not just give a link to a qemu image with a script that runs it?

Yes!

In an era where most development-oriented software is downloaded with wget/git clone/[package manager] install, this whole process feels like a slap in the face. And don't get me wrong, this is still a huge upgrade over the InstallShield Wizard of the previous versions, which rarely worked at all, and if it did, it would butcher your /etc/profile, but its still an absolute abomination, bundling an entire JRE for the only rightful architecture x86-64 just to download and unzip a few files.

Re: QNX Self-Hosted Developer Desktop

#155
post #91

PREEMPT_RT, Toyota's IVI shell for flutter and the AGL efforts has made qnx compete again

It's not a hard-running race. PREEMPT_RT is soft realtime and if you rely on it for your brakes you're going to crash. AGL has not yet produced any kind of usable system that can be certified for functional safety under ISO 26262 or IEC 61508. Just a core kernel with no drivers. We run into a lot of OEMs who switch to Linux because of AGL and come crawling back to QNX many expensive months later to start over with a…

Toyota has adopted the flutter IVI shell in their newer cars. You could argue that it can also run on QNX but the real push behind it has been the growing interest and effort behind AGL.

QNX hypervisor architecture allows companies to adopt AGL gradually bringing in the productivity benefits of stuff like flutter and Linux. QT is hell, their entire moat has been the automotive industry/highly embedded devices and seeing Flutter chip away at even a small portion of it gives a lot of hope for a better competitive landscape for more productive and performant embedded guis.

Re: QNX Self-Hosted Developer Desktop

#156

Earlier quoted context omitted.

Seems like QNX was hiding in plain sight as a car os and a mission critical os for other devices.

We're definitely a secret ingredient brand... hiding in products you use every day!

We're geeks: I know my car is running QNX for it's nav and audio (and certainly some other things) and, as a geek, I love it. So thank you so so very much! (it's a Porsche from 2013 btw)

Re: QNX Self-Hosted Developer Desktop

#157

Earlier quoted context omitted.

Seems like QNX was hiding in plain sight as a car os and a mission critical os for other devices.

I think the market is moving to "mixed criticality" so you can use Linux for your entertainment system but then also use a proper RTOS for the car stuff all in the same SoC.

Yup, similar for audio stuff.

Re: QNX Self-Hosted Developer Desktop

#158
post #27

I always liked their original UI - Photon[1][2]. Very lightweight and fast. Also a distinct and consistent style. I understand why they dropped it in favor of Qt and later Web technologies, but it's still a big loss. [1] https://www.qnx.com/developers/docs/6.5.0SP1.update/com.qnx.... [2] https://www.mikecramer.com/qnx/momentics_nc_docs/photon/prog...

Indeed. QNX is the coolest OS I ever seen and Photon felt the coolest desktop environment. Although I like XFCE in the Linux context (more than e.g. GNOME), I am sad to see it replaced Photon on QNX. Photon just looked and felt so lovely and came with a visual C++ builder making GUI apps development so nice.

I ever saw.

I have ever seen.

Re: QNX Self-Hosted Developer Desktop

#160

Earlier quoted context omitted.

I would like to hear more about your experiences. What makes QNX better than others?

Show me another OS that you can undress to the kernel, a console, a file system and a disk driver and then build it all up again without missing a beat. The kernel processes are actual processes so each of the drivers is fully sandboxed, an error in one bit of code can not cause any other processes to be affected unless you explicitly declare that it should be so (shared memory, for instance) and of course you don't…

Is this true? [0] No CVEs since 2011?

[0] https://www.cvedetails.com/vulnerability-list/vendor_id-436/...

Post reply on HN