[spc476]

The QNX shell could easily do remote execution. I worked at a company in the mid-90s (porting Unix software to QNX). My machine had a modem on it, and my boss (the owner of the company) would use it from his computer to dial out---all he had to do was reference the modem device on my computer at his command line.

In fact, you could run a program on a local machine referencing a file on a second machine, pipe the output to a program on a third machine and have that redirect the output to a file on a fourth machine, all from the command line. I don't recall the exact syntax, but it was something like:

    cat @2/path/to/large/file | @3/bin/grep 'foo' >@4/tmp/output

(Individual hosts were numbered on a QNX ethernet based network, but the default permmissions were Unix like). All of this was a consequence of the message-based QNX operating system (whether messages were delivered locally or remotely was invisible to programs) but I don't see why something like can't be done today.

[dmytrish]

This is a quite neat example, but it looks like the QNX shell mixed several concerns about how do you connect to these machines, how do you secure the communication, etc.

    $ ssh @2 "cat /path/to/large/file" | ssh @3 "/bin/grep 'foo'" | ssh @4 "cat >/tmp/output"

is rather clunky, but separates those concerns well.

[spc476]

Sorry about not getting back sooner (returning from vacation) but the QNX network message passing ran over Ethernet, not IP, so it only worked (to my knowledge) over a local segment. Given that it was transparent to user processes, it could be argued that security could be added at that layer (two of the seven layer OSI model).