I'm having a problem with talk.. if someone is talking me,
I can't reply... ex:

Message from forsaken@grex.cyberspace.org.
Reply with !talk forsaken@grex.cyberspace.org (or whatever it says, etc)

!talk forsaken@grex.cyberspace.org

[Unable to connect with initiator : Permission denied (13)]

Wherein it sends me back to wherever I was.  Any ideas?  Thanks.

25 responses total.

Have you tried using "ntalk"?

I remember having a *different* problem with "talk"

This response has been erased.

 there is a problem. Every time I try to !talk with layers activated,
it tells me it doesn't know who I am.
.,

That's because layers has two modes. It has been running in a
semi-installed mode in which it doesn't put entries in a certain
system file that talk expects to see. This confuses talk.
ntalk works however.

Now layers appears to be installed in a more complete fashion.
I'll bet that the problem has disappeared. I would still recommend
the use of ntalk over talk.

I just had an ntalk session going in each of two separate layers windows.
It was hectic, but worked flawlessly.

 what do I have to do now to activate layers? /u/srw/layers/layers is
de-permed.

Sorry about that. i forgot the perms.
layers has now been installed in the system. if you type /u/srw/layers
you were supposed to get a message saying just say "layers".
Anyway, remember to say !layers if you're at picospan's OK prompt.

I entered !layers at the Ok: prompt and got
  You are not running under MacLayers.
!
I thought that was stating the obvious, but less than helpfully.  Did I
miss something?  How am I supposed to *start* running layers?

Well, talk just failed with a newuser, who just might not come
back, he was already pissed from a write session that munged.
  
Again the  (permission deinied (13) popped up and I was the 
initiator, and then he was the initiator, and (perms denied (13)
resulted when I tried to respond.
  
Of course neither of us had our perms off, I checked, (if that
informatin is still available as before)
  
So it's not fixed. We were each running    vt100 emulation, btw.
  

re 8. you're comm program must be MacLayers. Once you are connected to
grex, and are at the grex% prompt (csh) type layers or at the OK: prompt
!layers. What happens next, is your comm program will drop for a bit,
and you'll see "HostLayers activated" and then everything will go back
to the prompt that you were at.

Maclayers has been discussed extensively in the micros conference in
item number 70. If you read that, other guy, and want me to, I'll be
happy to put a copy of the client (mac) program "MacLayers" on grex
for you to download it. Disk space limitations prevent me from
leaving there permanently.

Sounds good.  Thanks!

Download the file /u/srw/maclayers1.30.sit.hqx
it's 200k so allocate some time for this.
After you get it unbinhexed and unstuffed you should be in business.

For those of you not on Macs, there is also a really nice program available
on grex called "screen". Screen can create up to 10 virtual terminals and
you can hotkey back and forth between any of them. *And* you can do this
on any connection, even a dumb terminal.

As long as you can clear your screen. I wouldn't suggest it on a tty.  :-)
Actually, this talk problem is something I don't think is right.  If I cant
talk to users locally, that is a problem.  Perhaps we should have a
optin in the proram to restrict it to offsite if you want to be that picky.
Allowing offsite talk isn't evil either.  They worry about offsite telnet
mostly.  ANd with all this net "verification", could someone then explain
"anonymous" ftp to me again?  It's getting out of hand.

There are about 5 different problems being discussed in this thread, and I
think they are all fixed or explained, with the exception of tsty's #9. 

I am puzzled by this problem. talk should work fine for non-members
talking on-site. Did you try 'which talk' to see of you are picking
up talk from a strange place rather than /usr/ucb/talk  ts?

The question what activity should be allowed to whom is going on in 
coop #83. 

Regarding "anonymous" FTP -- it has only been so for the time when it
was not feasable to make it non-anonymous.  Nowadays it's more like
"public" FTP -- your hostname, and possibly your login-id, is
usually recorded in a log file.  Every file you download or upload
is probably logged, too.

That might be the purpose of asking for the password when logging in.  However,
I have noticed that FTP sites must not care what you type in as a password.
I am not a very accurate typist when I can't see my letters coming up on
the screen, and yet I have never been shut out by an FTP site for mistyping
"scg@cyberspace.org".

program it into a macro key, Steve.
The nature of the connection implies that it's not impossible for them to
record who you are at the time the connection is made, whatever you mistype,
I think.

The @ sign seems to be the key.  Leave that out on some ftp sites
and you'll get a polite message about using your real email address
next time.  I don't think I've ever been shut out (though garbo.uwasa.fi
does state that repeated abuses of the email password coming from one
site will cause that site to be locked out).

Yes, you could type in flooble@blarby.org and it would accept it as a
password. It's mostly there so they can gather usage statistics.
However, there are other ways to keep track of what site the connection came
in from, so don't believe that we can just ftp anywhere you want and
not have anyone know who you are.

After reading all the aforementioned responses, I couldn't gather how to talk
successfully, same initiator problem . I tried ntalk also but in vain.

Did you check the permissions on both sides?  (Yes, TS did report a
case where he checked this & still failed to connect.  Still, that's
the single most likely problem unless you made *sure* you both
had your perms turned on.)

This response has been erased.

This will be fixed soon, when the kernel blocks are updated.

Response not possible - You must register and login before posting.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss