3 ms·
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
by spc476 11y ago
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 11y agoThis 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 11y agoSorry 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).