RFC: QNX4 vs. QNX6

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
101

“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:aelj62$pde$1@nntp.qnx.com…

Let me play Devil’s advocate some more.

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.

You don’t but legaly if you want to support phditto your tarket must have
a Photon license, that means extra cost, not good

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?

Could be if you install lots of machine in the field.

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 don’t necessarly want to log errors, program may want to display
what they are doing, logging in a system without HD or Flash is a pain…

You have obviously never use ditto Kris :wink:

Kris

“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:aeldpa$ks3$> 1@nntp.qnx.com> …
Jim Douglas <> jim@dramatec.co.uk> > wrote:

“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:ael825$h4u$> 1@nntp.qnx.com> …
I’ve seen a number of requests for ditto and I was wondering if there
was
a
really compelling reason why we would still need this. We’ve got
phditto
which seems to be quite a bit more powerful. We’ve got telnet which
is
relatively secure and portable. I know it was something that people
liked
once upon a time but I’m wondering if perhaps this is a bit of
nostalgia
as
opposed to an actual need.

Nostalgia! doh - join the real world8-) We are talking simplicity and
ease
of use…

  1. It can work without Photon so it can give you a command line
    interface on
    to your target while you fight to get Photon up and running.
  2. The assumption is that it will work over QNet without having to
    struggle
    with the intricacies of TCP/IP.

It is also VERY important to telnet into a remote node, ditto to it’s
console to see what system error dumped there.

-xtang

102

“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:aele81$ev5$1@inn.qnx.com…

Does it work in text mode?

No it doesn’t

“Jim Douglas” <> jim@dramatec.co.uk> > wrote in message
news:aekg69$mr6$> 1@inn.qnx.com> …

andy@microstep-mis.com> > wrote in message
news:aejs40$6oh$> 1@charon.microstep-mis.sk> …

[…]

my proposal: vedit or vp

For those of us not brought up on a diet of vi/jed/emacs etc, and who
mourn
the loss of vedit/vplus, there may now be a suitable replacement. Check
out
Workspace at pages.infinit.net/micbel. I have not used it in anger as
yet,
but it seems to have all the facilities an ex-vplus user like me would
ever
need.> :sunglasses:

Jim

\

103

Xiaodan Tang wrote:

Armin Steinhoff <a-steinhoff@web_.de> wrote:

Xiaodan Tang wrote:

. What I am more interested in is a QNET based, “made by QNX”, distributed
system.

I would go with a middleware STANDARD and not with this uncomplete aria
called QNET.

Nah, you probably didn’t realized the power of message-passing
system.

There are no reasons not to use message passing of QNX for MPI/RT

(With things
like remote spawn, remote fork, job scheduling …)

It’s covered by the MPI/RT standard.

It is? Last I read MPI 2.0, it only defining basic message passing.

Nah … you have to read the MPI/RT specification:
http://www.mpirt.org.

And “remote fork” is very difficult (even on QNX6 system), and
I really doubt you can do that on triditional system.

MPI/RT defines the interface at application level … not the
implementation.

Regards

Armin

104

“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:aelj62$pde$1@nntp.qnx.com…

Let me play Devil’s advocate some more.

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.

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?

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?

I think others have answered the above much as I would have, so let me put
approach matters from a slightly different perpective…

I came to QNX4 from the MS camp (escaped perhaps8-) and I carry no
Unix/Linux baggage. What attracted me was a superb RTOS with the benefits of
a Unix-like system but with a number of very POWERFUL and EASY-TO-USE
features that set QNX apart from the rest of the herd. In the main these
were -

QNX native networking with name location, IPC and media independence.
Ditto
The Photon “Jump Gate”
The ability to run a single Photon desktop over multiple video cards and/or
nodes.

The point being that anybody with half a brain can produce stunning results
very quickly by harnessing the power of these sort of facilities. OK, the
results are not portable and possibly not POSIX compliant, but who cares
when you can achieve (and usually exeed) your goal in half the time? I have
managed to produce a number of (QNX4) networked products so far without
knowing the first thing about TCP/IP. I won’t start down the QNX6/QNet rocky
road…

QNX6 is a “me too” OS and QSSL seems to have lost sight of what made QNX4 so
understandable and attractive to non-Unix programmers. Any wrappers that can
be placed around intricate features to hide the complexity are welcome to
me - Ditto being one such.

Jim

105

Jim Douglas wrote:

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3D0E03E1.E640460D@web_.de…


Jim Douglas wrote:

My wish is that you would fix QNet to be as good as the QNX4 native
networking -

  1. Make it reliable. At present there are too many errors and loss of
    service.

  2. Make it work over a serial link WITHOUT having to use TCP/IP and PPP
    as
    well.

  3. Make the ndp reliable and predictable and make it work over any type
    of
    link. At present it does not work at all over a serial link.

  4. Come up with a name location scheme (or similar) that is as good as,
    or
    better than nameloc so that it is technically possible to configure a
    logical system without regard for the physical network it runs on.

This is just an outline - if you want me to go into more detail just
ask…

Hmm … what you are requesting is a cluster middleware. Use PVM > :slight_smile:

Forgive the ignorance - can you please explain?

All cluster middle-ware (PVM. MPI, Beowulf MPI/RT… ) are interface
definitions for the application level … that means they are
independent from the communication intrastructure. There are
implementations based on shared memory, 100MB/s Ethernet, Gigabit
Ethernet, Myrinet and others.

All applications using the standard interface at application level are
system independent … there is a lot of re-usable software (netlib.org)

Every proprietary middleware solution starts with ZERO software …
that means the accetptance will also be ZERO.

My proposal is to use MPI/RT as the STANDARD real-time interface at
application level for distributed QNX systems.

MPI/RT should then be implemented on top of QNX message passing and/or
UDP. It is always possible to use different communication media
like serial links or shared memory …

Regards

Armin




Jim

106

“Xiaodan Tang” <xtang@qnx.com> schrieb im Newsbeitrag
news:aeldpa$ks3$1@nntp.qnx.com…

Jim Douglas <> jim@dramatec.co.uk> > wrote:

“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:ael825$h4u$> 1@nntp.qnx.com> …
I’ve seen a number of requests for ditto and I was wondering if there
was
a
really compelling reason why we would still need this. We’ve got
phditto
which seems to be quite a bit more powerful. We’ve got telnet which is
relatively secure and portable. I know it was something that people
liked
once upon a time but I’m wondering if perhaps this is a bit of
nostalgia
as
opposed to an actual need.

Nostalgia! doh - join the real world8-) We are talking simplicity and
ease
of use…

  1. It can work without Photon so it can give you a command line
    interface on
    to your target while you fight to get Photon up and running.
  2. The assumption is that it will work over QNet without having to
    struggle
    with the intricacies of TCP/IP.

It is also VERY important to telnet into a remote node, ditto to it’s
console to see what system error dumped there.

And this way you can watch whatever the user is typing on his console.

This makes telephone support much easier, some times.
Werner Schweizer

107

I think it’s important to keep in mind that much of the QNX4 world was based
on the “x86 assumption”. Ditto’ing a terminal from a different platform
isn’t as straight forward as you’d think. While I agree that the tool was
useful, perhaps instead of replicating the old chain, advances should be
made to make better tools that incorporate similar functionality.

Also, replicating all the “sin functionality” isn’t as straightforward (or
relevant either) and requests to do so, should be taken with a grain of
salt. We have other system introspection tools (instrumented kernel &
assoc. tools) can which provide much more insight into system behaviour. By
no means am I saying that pidin’s functionality should be curtailed, just
that everyone keep in mind that just because old tools do “function x”
doesn’t mean the new ones should.

IMHO, limiting ones thinking to “this is the way it should be done”, is just
that… limiting.

–
Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

<camz@passageway.com> wrote in message news:aelknn$i9p$6@inn.qnx.com…

Xiaodan Tang <> xtang@qnx.com> > wrote:
Oh, and nobody want “sin vc” ?

Oh yeah. We kinda covered that. I think we said “duplicate ALL the
functionality of sin from QNX4”

Cheers,
Camz.

108

I think this should be taken to a different newsgroup for further discussion
(tools comes to mind).

–
Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:aelj8n$pm5$1@nntp.qnx.com…

Noted and added.

Kris

“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:aele97$ks3$> 3@nntp.qnx.com> …
Kris Warkentin <> kewarken@qnx.com> > wrote:
Attention QNX users.

I am compiling a wish-list for utilities development over the next 6
months
to a year. I’m mostly looking for things that existed in QNX4 but
don’t
in
QNX6 but I’m also taking general utils feature requests.

So, if there are any utilities you wish you had or enhanced
functionality to
existing utilities, now is the time to let me know so I can try to get
them
on the road map.

Oh, and nobody want “sin vc” ?

I really like to know who the hack it is, when my harddisk suddenly
keeps on busy while I was just stare at my screen > :slight_smile:

-xtang

109

Actually, it isn’t just my list. I nominally own utilities but there tends
to be overlap from other departments. For example, something like whois
would be owned by the networking group and something like having diskboot do
fscks at startup would be filesystems/OS group.

As far as which ones get approved/rejected, I don’t know if that will become
public knowledge. I would expect that most of our roadmap will be company
confidential but it may be that we’ll be sharing parts of it. For example,
one of the suggestions for PAM came along the lines of, “If you don’t do it
in house, then release the source for login/su/passwd so we can do it
ourselves.” Well, one of the roadmap activities will be deciding which
things to open the source for so a response might simply be some new source
appearing on the public CVS.

cheers,

Kris

<camz@passageway.com> wrote in message news:aellrr$k19$2@inn.qnx.com…

Kris Warkentin <> kewarken@qnx.com> > wrote:
Okay, okay…don’t panic. > :wink: > I’ll put it on my list. You know, my
list
is getting really big…if management approves half of these projects
I’m
going to be really busy.

Actually, I think everyone that has contributed to this list would like to
know which ones they approve and which they do not. The list shouldn’t be
exclusively your to do list either, I’m sure there is enough (or will be)
for
a couple developers @ QSSL to be busy for a while.

If management rejects ANY of the requests, this group will want to know.

Cheers,
Camz

110

<camz@passageway.com> wrote in message news:aelkhp$i9p$5@inn.qnx.com…

You’ve obviously never been in the position of supporting a system from
remote or you would never be asking this question.

Considering that I was sysadmin for my university’s computer science
department for 2 years, I certainly have been in this situation and I can
understand the usefulness of ditto. I also understand that any remote host
running qnet is wide open and to suggest that leaving qnet running on a host
which is accessable from elsewhere is a viable solution to the remote admin
situation is madness. A solution that I used in the past for remote console
access was to have a modem hooked to a serial port and a console running on
it. This also has it’s problems but you do what you have to do and try to
make it as secure as you can.

The main situation I can see ditto being useful is in the development lab.
We have a lab full of targets that people in the building can access. If
they crash the machine, it’s handy for them to have a console so they don’t
have to run into the lab to see what happened. Consider this however:
qnet, as of yet, does not function properly between machines of different
architecture. So, even if it were to exist, we can’t guarantee that it
would work anywhere other than x86 to x86.

I know that this is something many people want. Rest assured that I’m not
filtering the suggestions and that ditto will be on the development list
that I submit. What I’m giving you is a little bit of the cost/benefit
analysis that this will have to go through for management approval. There
was a significant amount of plumbing in the qnx4 console driver for this to
work. Apparantly the guts of ditto was all of about a dozen lines of code
since the heavy lifting was hidden behind the console interface. If it’s
going to be re-implemented for qnx6, then we’d better a) have a pretty good
case for why we need it, b) at least an idea of how we’re going to implement
it in a portable way and c) an estimate of just how much work b will be.

cheers,

Kris

Cheers,
Camz.

111

“Mario Charest” postmaster@l127.0.0.1 wrote in message
news:aelv62$qdi$2@inn.qnx.com…

“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:aelj62$pde$> 1@nntp.qnx.com> …
Let me play Devil’s advocate some more.

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.

You don’t but legaly if you want to support phditto your tarket must have
a Photon license, that means extra cost, not good

I’m not 100% sure but I don’t believe that photon is a separately licensed
product anymore.

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?

Could be if you install lots of machine in the field.

You left qnet running on your machine in the field?

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 don’t necessarly want to log errors, program may want to display
what they are doing, logging in a system without HD or Flash is a pain…

You have obviously never use ditto Kris > :wink:

No and believe me, I do see the value of it. If I’m to make a case for it
though, I will have to convince other people as well.

Kris

“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:aeldpa$ks3$> 1@nntp.qnx.com> …
Jim Douglas <> jim@dramatec.co.uk> > wrote:

“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:ael825$h4u$> 1@nntp.qnx.com> …
I’ve seen a number of requests for ditto and I was wondering if
there
was
a
really compelling reason why we would still need this. We’ve got
phditto
which seems to be quite a bit more powerful. We’ve got telnet
which
is
relatively secure and portable. I know it was something that
people
liked
once upon a time but I’m wondering if perhaps this is a bit of
nostalgia
as
opposed to an actual need.

Nostalgia! doh - join the real world8-) We are talking simplicity
and
ease
of use…

  1. It can work without Photon so it can give you a command line
    interface on
    to your target while you fight to get Photon up and running.
  2. The assumption is that it will work over QNet without having to
    struggle
    with the intricacies of TCP/IP.

It is also VERY important to telnet into a remote node, ditto to it’s
console to see what system error dumped there.

-xtang
\

112

Thank you Jim. That is one of the best bits of advocacy I’ve seen yet.

cheers,

Kris

“Jim Douglas” <jim@dramatec.co.uk> wrote in message
news:aemq00$ftj$1@inn.qnx.com…

“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:aelj62$pde$> 1@nntp.qnx.com> …
Let me play Devil’s advocate some more.

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.

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?

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?

I think others have answered the above much as I would have, so let me put
approach matters from a slightly different perpective…

I came to QNX4 from the MS camp (escaped perhaps8-) and I carry no
Unix/Linux baggage. What attracted me was a superb RTOS with the benefits
of
a Unix-like system but with a number of very POWERFUL and EASY-TO-USE
features that set QNX apart from the rest of the herd. In the main these
were -

QNX native networking with name location, IPC and media independence.
Ditto
The Photon “Jump Gate”
The ability to run a single Photon desktop over multiple video cards
and/or
nodes.

The point being that anybody with half a brain can produce stunning
results
very quickly by harnessing the power of these sort of facilities. OK, the
results are not portable and possibly not POSIX compliant, but who cares
when you can achieve (and usually exeed) your goal in half the time? I
have
managed to produce a number of (QNX4) networked products so far without
knowing the first thing about TCP/IP. I won’t start down the QNX6/QNet
rocky
road…

QNX6 is a “me too” OS and QSSL seems to have lost sight of what made QNX4
so
understandable and attractive to non-Unix programmers. Any wrappers that
can
be placed around intricate features to hide the complexity are welcome to
me - Ditto being one such.

Jim
\

113

Kris Warkentin <kewarken@qnx.com> wrote:

understand the usefulness of ditto. I also understand that any remote host
running qnet is wide open and to suggest that leaving qnet running on a host
which is accessable from elsewhere is a viable solution to the remote admin
situation is madness.

It depends on the environment, and in all honesty, qnet and ditto are not
really related.

A typical support scenario is this:

[Phone Rings, 3:00AM]
TECH: Hello?
USER: The system is broken.
TECH: That’s not very helpful, what isn’t working.
USER: I don’t know, it just won’t work
TECH: Okay, give me a couple minutes…
[Tech fires up telnet and connects to the remote netowork]
TECH: What node is that? It should say “Node 20” or some number on the monitor.
USER: It says “Node 17”, is that what you need?
TECH: Okay, that’s what I needed, thanks.
[Tech fires up ditto -Vkn17 to connect to the node’s console]
TECH: Ah, I see what’s going on, the PLC control process received an E-STOP
USER: It did? I didn’t see any red light on the light tower?
TECH: Well, it’s E-STOPPED, maybe there is a burnt out bulb in the light tower?
USER: Uhm, I’ll check
USER: Yeah… bulb is burnt out, what do I do?
TECH: Well, find the E-STOP button that’s pressed and release it
TECH: Then call maintenance and get them to fix the bulb in the light tower.
USER: Thanks!
[Hangs up]
[Tech goes back to sleep]

As you can see QNET / FLEET isn’t involved. I don’t want this to degrade
into a debate over the security model of QNET / FLEET.

We are all asking for ditto because it’s usefull and it makes out lives much
easier. In all honesty, since we (the customer) never saw the internal guts
that were required to make ditto work, that really doesn’t matter to us.
What matters is that ditto worked, and it provided a huge advantage to us in
the area of support. You’ve had quite a few instances of how people used it
in QNX4.

A solution that I used in the past for remote console
access was to have a modem hooked to a serial port and a console running on
it.

The thing with being able to ditto a console is that you have at least 25 lines
of history/context. If you use a serial console then it has to be connected
to something that actually logs the data/messages that it spews out, and then
you need remote access to THAT system.

The main situation I can see ditto being useful is in the development lab.
We have a lab full of targets that people in the building can access.

It’s useful in the development scenario, absolutely. Not all companies will
actually have a lab though. It’s useful for supporting servers (be they
file servers, web servers, network gateways, etc.)


Consider this however:
qnet, as of yet, does not function properly between machines of different
architecture. So, even if it were to exist, we can’t guarantee that it
would work anywhere other than x86 to x86.

Actually that is not correct. Qnet does not function between machines of
different endian-ness. I have run qnet between an ipaq and an x86 desktop,
it worked extremely well.

I know that this is something many people want. Rest assured that I’m not
filtering the suggestions and that ditto will be on the development list
that I submit. What I’m giving you is a little bit of the cost/benefit
analysis that this will have to go through for management approval.

The cost/benfit is in the productivity of your customers/users, I have no
idea what sort of cost/benefit or ROI you need to show management before
you can proceed, but I suspect it would be different than the cost/benefit
customers receive by the existence of the tool.

going to be re-implemented for qnx6, then we’d better a) have a pretty good
case for why we need it, b) at least an idea of how we’re going to implement
it in a portable way and c) an estimate of just how much work b will be.

Heh, heh. You know we never saw those guts, so we don’t care. We had it.
It worked. If the guts were ugly, then you should “do it right / better
this time”. Consider this a chance to redeem yourself. :slight_smile:

Cheers,
Camz.

114

Kris Warkentin <kewarken@qnx.com> wrote:

Actually, it isn’t just my list. I nominally own utilities but there tends
to be overlap from other departments. For example, something like whois

Since whois is such a simple utility and important to Rob, here it is
http://qnx4.wox.org/whois.gz
download and gunzip it, put it anywhere you want, say /usr/bin

Frank

115

[snip]

I find ditto very usefull in remote system administration and diagnosis. I
usually get into target system (either via modem console or via telnet),
then use ditto to see other consoles. Some programs do output some usefull
data to consoles and sometimes I need to see that information.

In QNX6 there is no way to see that information. If I am wrong, please
correct me.

There is some discussion about ditto, qnet and endian-ness. For my remote
system administration I would be happy to live with “local” ditto, with no
qnet functionality.

Pavol Kycina

116

Adam Mallory <amallory@qnx.com> wrote:

I think it’s important to keep in mind that much of the QNX4 world was based
on the “x86 assumption”. Ditto’ing a terminal from a different platform
isn’t as straight forward as you’d think. While I agree that the tool was
useful, perhaps instead of replicating the old chain, advances should be
made to make better tools that incorporate similar functionality.

I don’t think ANY of use really care if it was tied to x86 or not. It provided
a useful function. As Mario points out it has uses where you used Dev.ditto
to create a console for a system (embedded target) that might not have had
a real console at all. This is probably a scenario that is quite common in
the “new world” that QNX6 exsits in. Not all non-x86 platforms have the
concept of a console. The concept of a console is very useful, and appears
in many situations, both javascript and java virtual machines provide a
“console”. These are not related to the underlying hardware at all. The
concept of a “console” is 100% valid and useful.

So, don’t tie it to the x86/PC arcitechture where viewing the console is
nothing more than dumping some memory. Implement in a way that is dependant
on the OS architechture, not the hardware. io-char process with some
devctl()'s for accessing it, perhaps some helper functions that communicate
with io-char that allow any character-based devc-* driver to access to make
itself “ditto-able”.

Also, replicating all the “sin functionality” isn’t as straightforward (or
relevant either) and requests to do so, should be taken with a grain of
salt. We have other system introspection tools (instrumented kernel &
assoc. tools) can which provide much more insight into system behaviour. By
no means am I saying that pidin’s functionality should be curtailed, just
that everyone keep in mind that just because old tools do “function x”
doesn’t mean the new ones should.

Don’t treat us like idiots. We are asking for the functionality because it
was useful to us. Sure the instrumented kernel can give a good view into
a running system, and the various interactions. There was functionality and
information that sin provided that the instrumented kernel would not be able
to provide, at least not easily. What IRQ’s are in use? Sure, some IRQ’s
that a driver should use are specified on the cmdline, most however are
auto-detected. The instrumented kernel won’t tell me that. What files are
open? Who has them open? I need to run chkfsys on a filesystem, I need to
know what processes to kick that have files open for write on that partition
before I can proceed.

So, we ask for the functionality because it was useful to us, not simply
because “QNX4 had it”.

IMHO, limiting ones thinking to “this is the way it should be done”, is just
that… limiting.

We aren’t but there wasn’t much functionality in sin that wasn’t useful, so
asking for “all the functionality of QNX4 sin” is just shorthand for the list
of information it provided without having to list them all individually.
How you provide that information to us (ie. how it should be done) isn’t
relevent. Just provide the means for us to get the information. We don’t
have that right now. We’d like it.

Cheers,
Camz.

117

Hello folks

Sorry for my ignorance… but will it be too difficult for community to
make one if QSSL opens source to devc-con and devc-tcon ?

IMHO, a simple design where devc-con opens a “clone” device (eg.
/dev/ttyp1.ditto for /dev/ttyp1) and clones the content of the tty to it
BUT sends the current buffer to the client on connection to it should
suffice. Then using a simple terminal emulation program eg. a
(modified ?) qtalk , one should be able to connect to any console she wants.

–
Keep Smiling
Regards

  • mritunjai

http://www.me.iitb.ac.in/~mritun
http://www.qnxzone.com/~mritun
http://mritun.qnx.org.ru

118

Frank Liu <liug@mama.indstate.edu> wrote:

Kris Warkentin <> kewarken@qnx.com> > wrote:
Actually, it isn’t just my list. I nominally own utilities but there tends
to be overlap from other departments. For example, something like whois

Since whois is such a simple utility and important to Rob, here it is
http://qnx4.wox.org/whois.gz
download and gunzip it, put it anywhere you want, say /usr/bin

Thanks Frank! :slight_smile:

Cheers,
-RK

–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

119

Kevin Stallard wrote:

I guess I’ve adopted the philosophy that a
binary should have one receive and if it needs to start a thread to handle a
request, then so be it. The context switch time in QNX being so low, I
guess I lean towards creating a separate process if I come to a point where
I should be putting a MsgReceive() in a thread.

In all seriousness, this is a limiting philosophy. There is nothing wrong
with preferring a seperate process over multiple threads with differing
responsibilities; but there is also a lot “correct” about a dispatch
interface with a thread pool. Denying yourself this model, is IMO, very
limiting, but entirely within your rights; however, I, for one, want the
OS to support multiple models of application construction.

Rennie

120

Ultimately what is required to get the work done is to see exactly what
people want and how badly they want it. Since people quite often don’t
really know what they want, it’s better to look at what they need. That is,
“what problem are we trying to solve”?

At the top level the problem is, “Getting access to a remote machines
console”.

Questions that arise from that:

“Do you need write access or is read access sufficient?” Given that there
are other ways to execute processes on a remote machine, perhaps just being
able to read the console (especially if we were to cache a few pages) might
be enough.

“What level of security is expected?” Should it be safe to use over the
internet or strictly for internal use?

“What are the likely situations that this will be used for?” We have the
situation of the lab and the tech support. Are there others?

I’m sure there are others. I’m hoping that we can properly specify exactly
what the problem is, which will allow us to properly specify the solution.
We may find that parts of ditto will not be required because other
mechanisms exist. So far, most usage scenarios that I’ve seen come down to
“I want to see what is happening/has happened on the console” which is a
smaller problem to solve than the solution ditto provides. Perhaps a way to
start devc-con with a certain cache size and then an interface to retrieve
that information would be sufficient.

cheers,

Kris