Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a QNX 7 Desktop

membarrier.wordpress.com

Post reply on HN
Print view View original

51–60 of 94 posts

Re: Building a QNX 7 Desktop

#51

Post by fest »

vram22 wrote: post #49
geocar wrote: post #27

Earlier quoted context omitted.

I find a lot of similar joy working with Erlang. Having a proper (intra-application) messaging system makes a certain class of problems -- problems that you just get used to in Java, and Go, and Rust, and C/C++, and whatever -- just go away.

>Having a proper (intra-application) messaging system makes a certain class of problems -- problems that you just get used to in Java, and Go, and Rust, and C/C++, and whatever -- just go away. Interesting. Examples?

While I haven't used Erlang, I have used other systems with nice messaging systems (PX4 autopilot and ROS) so I will try:

1) Data is passed between threads/processes using a message bus (essentially, a queue). This means, no need to synchronize data access, as every subscriber gets it's own message copy.

2) Suddenly, you need access to certain data from another module. If the program was architected as regular class hierarchy, you would somehow need to pass the reference to that required class instance or use a global function call. If there is a message bus where the required class is already publishing messages, you can simply subscribe to data from the required module and it is delivered via message bus.

3) You can replace modules easily. The only interface to other modules is via message bus, so you can replace the module with one that publishes the same type of messages.

4) If the message bus is designed correctly, you can move the modules/process to different machines, and they can access the message bus over network. Bus broker just sends the messages over TCP instead and that is totally transparent for both involved nodes.

Btw, I am still looking for an infrastructure library just like that: https://news.ycombinator.com/item?id=14222202

Re: Building a QNX 7 Desktop

#52

Post by tyingq »

Frenchgeek wrote: post #25
shmerl wrote: post #14

Earlier quoted context omitted.

> It's what home routers and similar devices ought to be running instead of Linux. The bummer is that it's not FOSS.

Funny there doesn't seem to be an OSS attempt of something like it... ( Or my google-fu is weak )

FreeRTOS is here: http://www.freertos.org/

Though the "RT" is the only real overlap. It's targeted more at lower end hardware, but does have an x86 implementation.

Re: Building a QNX 7 Desktop

#53

Post by bluejekyll »

notalaser wrote: post #22
shmerl wrote: post #14

Earlier quoted context omitted.

> It's what home routers and similar devices ought to be running instead of Linux. The bummer is that it's not FOSS.

The bummer for the companies doing the home routers is really just that it costs money. The only people who give a flying fsck about the F part are hobbyists, sadly. Source: worked in this industry.

Not having a hobbyist option, means there are fewer people trying to use it for new and interesting things.

Re: Building a QNX 7 Desktop

#54

Post by bluejekyll »

digi_owl wrote: post #32
slobotron wrote: post #4

Nice work! Very tempted to try it out on a spare machine. Sure brings back memories of the fully functional QNX desktop that fit on a single 1.44MB floppy! [0] Tangent: It's a shame that Blackberry hasn't captured more of mobile phone market with the QNX based BB OS10 - I got myself a BlackBerry Passport couple months ago and find it is a great daily driver for my needs. Square screen (1400x1400) and physical keyboar…

When not even MS could muscle their way back in after burning their PocketPC bridge, BB didn't stand much of a chance.

Blackberry owned the market though. They were the corporate smart phone. They lost it all...

Has anyone written about what blackberry actually tried to do to prevent losing to Apple? My memory is that they basically were convinced there was no way they could lose their marketshare, so effectively just watched as they lost everything.

Re: Building a QNX 7 Desktop

#55

Post by feld »

tyingq wrote: post #48
feld wrote: post #44

Earlier quoted context omitted.

Which professional routers? Cisco doesn't use QNX and Juniper uses FreeBSD. I'm not sure there are any other router manufacturers that matter.

> Cisco doesn't use QNX Other than on their most expensive, powerful routers. https://en.wikipedia.org/wiki/IOS_XR

Wow, I forgot that even existed. Here I was thinking of every switch, firewall, and routing product they've done except this line. I guess it doesn't help that I've never had a reason to touch one as every carrier grade router I've used has been Juniper. I wonder why they went with a whole new platform based on QNX when you don't benefit from a realtime OS if all the packets are moved in hardware? Must be something about the pain of upgrades and reloads on other Cisco product lines and somehow QNX can minimize these outage windows.

I've still yet to meet someone who actually prefers Cisco over Juniper MX. I wonder who is buying these?

Re: Building a QNX 7 Desktop

#56

Post by terminalcommand »

fest wrote: post #51
vram22 wrote: post #49

Earlier quoted context omitted.

>Having a proper (intra-application) messaging system makes a certain class of problems -- problems that you just get used to in Java, and Go, and Rust, and C/C++, and whatever -- just go away. Interesting. Examples?

While I haven't used Erlang, I have used other systems with nice messaging systems (PX4 autopilot and ROS) so I will try: 1) Data is passed between threads/processes using a message bus (essentially, a queue). This means, no need to synchronize data access, as every subscriber gets it's own message copy. 2) Suddenly, you need access to certain data from another module. If the program was architected as regular class…

I don't have much experience in the field. Are you searching for something like Apache Kafka?

On the web page it states that Apache Kafka is a distributed streaming platform.

  Kafka has four core APIs:

    The Producer API allows an application to publish a stream of records to one or more Kafka topics.
    The Consumer API allows an application to subscribe to one or more topics and process the stream of records produced to them.
    The Streams API allows an application to act as a stream processor, consuming an input stream from one or more topics and producing an output stream to one or more output topics, effectively transforming the input streams to output streams.
    The Connector API allows building and running reusable producers or consumers that connect Kafka topics to existing applications or data systems. For example, a connector to a relational database might capture every change to a table.

Re: Building a QNX 7 Desktop

#57

Post by jacquesm »

fest wrote: post #51
vram22 wrote: post #49

Earlier quoted context omitted.

>Having a proper (intra-application) messaging system makes a certain class of problems -- problems that you just get used to in Java, and Go, and Rust, and C/C++, and whatever -- just go away. Interesting. Examples?

While I haven't used Erlang, I have used other systems with nice messaging systems (PX4 autopilot and ROS) so I will try: 1) Data is passed between threads/processes using a message bus (essentially, a queue). This means, no need to synchronize data access, as every subscriber gets it's own message copy. 2) Suddenly, you need access to certain data from another module. If the program was architected as regular class…

I built something very close to this but it's closed source and very unlikely to ever be released as open source. But it's doable. About 4 man-years of work.

Re: Building a QNX 7 Desktop

#58

Post by secure »

Animats wrote: post #10

That's nice, but sad. Until QNX 6.5, there was a full windowed desktop environment, with the Photon window manager. I used QNX on the desktop when developing a DARPA Grand Challenge vehicle from 2003-2005. Back then, at QNX 6.21, you had the window manager, the Eclipse development environment, Firebird (Firefox before the name change), and Thunderbird. Then QNX marketing cut off the free version, and all the free sof…

> The desktop environment had very consistent performance, because QNX doesn't swap. (It's a real time system, after all.)

Is it possible to configure Linux towards this sort of behavior? I disabled swap, and whenever my memory is exhausted aggressively (think a runaway program writing to /tmp, which is on tmpfs), my system comes to a grinding halt.

How does QNX deal with memory pressure?

Re: Building a QNX 7 Desktop

#59

Post by jacquesm »

rcarmo wrote: post #24

Transparent IPC over the network was the reason I set up QNX a long time ago (back when it was freely available for a bit). I can't help but wonder how a Raspberry Pi Port would fare - the thing would be tremendously efficient, and it would certainly increase their popularity. Edit: well, apparently someone ported QNX 6, but licensing requirements seem to curtail its use for hobbyists - https://github.com/varghes/Ras…

They'll never get it. They could really own the space and be a serious competitor to RedHat. Especially with all the self-driving car research and other real time tasks QNX would rock if it were open source.

Re: Building a QNX 7 Desktop

#60

Post by jacquesm »

i336_ wrote: post #20

> QNX was cautiously courting the open source concept and venturing in the direction of shared source (with some code already available), when BlackBerry bought them and threw all of that out the window. Biggest yanked opportunity. D: I said that ^ last time QNX got brought up: https://news.ycombinator.com/item?id=12777520 Quick UNix (QUnix, which became QNX "after a brief infestation of AT&T lawyers" - https://news.…

I've gone that road, even had financing lined up for a 'ransomware' style buy-out. Nobody even wanted to talk.

Very frustrating.

I completely share your sentiment and your vision.

Post reply on HN