Kris Warkentin <email@example.com> wrote:
Let me play Devil’s advocate some more.
Sure, but you DO know that you are up against people that have been using
ditto on QNX4 for years, supporting REAL production envirionments.
A) You don’t need a full graphical photon running on your client to get
phditto. This I have on authority from Gord Bell himself who phdittos from
his qnx6 box to a qnx4 box in a closet which doesn’t even have a keyboard.
No, you don’t. I use this all the time too, that is one area where phditto
has more functionality that plain old ditto. phditto will create a new session
OR connect to an existing one. ditto can only connect to existing consoles.
You keep forgetting that phditto and ditto do not provide the SAME functions
they provide COMPLIMENTARY functions. If you can see the merit/benefit of
having phditto available for connecting to the grpahical console of a QNX
Photon box, then you should be able to see the advantage of being able to
connect to the text console as well.
Hell, I have made embedded systems in QNX4 with no video hardware, that used
phindows/phrelay as the primary interface, 100% graphical.
So, please… get this through your head.
DITTO != PHDITTO
B) If you have QNET running, you have all the plumbing in place for tcp/ip.
Is it that hard to give your box an IP?
Actually, ditto on qnx4 was able to use FLEET, aka QNET in qnx6. ditto would
be able to connect to the console of any machine in a QNET network, without
the need for TCP/IP at all. FLEET could actually run over non-TCP/IP networks
C) If you’re relying on the system console for error logs, don’t you think
you should be rethinking things a bit and using an actual log?
You often do not have control over all the apps/utils running on your
system. More often than not, it is a 3rd party app, or even a QSSL app or
driver that spits out the message. As an example, if a process SEGVs that
was started from rc.local, the SEGV error message will go to /dev/con1
(okay, actually… /dev/text). If dumper is not running (quite possible
for an embedded device in a production envirionment) then getting this info
from the console is the ONLY way to get the info.
So, you are correct, programs should log their error messages to syslog or
tracelogger, or something to that effect. A properly designed one should.
Not all do.
Go through the QSSL ones, and I doubt you will find that all of them dump
all their error messages to a log utility in addition to printing them out
to stdout or stderr or /dev/text. Reminds me of something I heard about
people that live in glass houses…