Re: NOS is evil

[ron@chaos.eng.wayne.edu (Ron Atkinson)]

Well Brandons reasons for writing JNOS/Linux is pretty obvious if you
just read his README file in that he wants to maintain a firewall
between his Linux system and a more packet users oriented NOS system.
This is what most people are doing.  It's kinda like running DV or
Windows and you also have NOS running on the machine.  Although the 
problem is what you describe, there is already TCP/IP in the kernel
and that should be used instead.   I've run the AX.25 in the Linux kernel
and pretty much beat on that for a while and it runs pretty good if
you hvae a very good link and you don't have retries.  Your everyday 
normal joe ham on packet usually lives in an environment of lots of
people sharing a frequency and there are hidden terminals and retries
occuring all the time.  AX.25 in the Linux kernel really sucks rocks
big time in this environment.  That's when you fire up JNOS or TNOS
for Linux and use that implementation since it's designed to work in
that kind of environment.  Now if you have good links like you should
have and there are very little retries and data hums along with no problem,
then AX.25 in the kernel works great.  

The needs to be just a bit more work done in the code to operate 
in a more 'real world' environment for it to work correctly like 
what you describe, and due to that reason a lot of people that I've
noticed have gone back to JNOS or TNOS since they don't like it when the
Linux system backs off and just sits there for a very very long time
not doing anything.     Of course if we all fix the physical layer
like we should then this problem shouldn't exist  :-)

Also what really needs to exist is a friendly interface for the users. 
The first time I added some users into my Linux system when I was
running AX.25 in the kernel and they telnetted to me they were stuck in 
character mode and they got the  bash  shell prompt.  Then they
do the usual and type   help  and get a cryptic looking BASH shell
help screen. Fine if they want to write a script, but to use my system
they basically have to know Unix. When I put JNOS and later TNOS on they
are happy again.   I would really love to see some timer changes in the
AX.25 code done first and then take a BBS type program that everyone is
used to seeing and using (or a better one that can work over packet) and
use the TCP/IP in the kernel rather than NOS.   JNOS and TNOS are pretty 
cool...  but I do also agree that it's not the real way it should be
done.  I gave up on doing stuff like adding servers into NOS since I
already have them under Linux right now, but it all still comes down
to the bad physical layer that exists on packet that makes it not
work very well (I know some people have 56k links and such, but
most don't).

I'd also like to see something done for other systems liks OS/2 and Windows.
Sure Trumpet Winsock exists and Warp has TCP/IP, but they suffer from the 
same problem as AX.25 in the kernel.  What I'd like to see here is Phil's
base code gutted and rip the servers right out and just use the AX.25 and
TCP/IP part. Then put a Windows Socket interface on it and you can run 
all the neat Windows and OS/2 applications you want.  Don't like an FTP
server, fine, dump it and run another one.   The main code to handle the
connects is actually a TCP/IP package designed to run over packet radio.
This is what Johan WG7J wanted to do after he quit doing JNOS development.
This would also function very similar to what Unix systems are doing
now.  Then maybe if some BBS author added a sockets interface on their
program it could then be ported over to a Unix platform and ran with a 
dedicated login or a connect to a specific port.

-- 

Ron Atkinson  N8FOW

AMPRnet  : n8fow@n8fow.ampr.org
Internet : ron@chaos.eng.wayne.edu
           aa011@detroit.freenet.org