2 Aug
2022
2 Aug
'22
7:09 p.m.
By real I suppose I meant mostly non system administration type uses - not
my best word usage. All I'm particularly interested in is some system and
network administration type tools, primarily the tools and protocols needed
to support terminal sessions and file transfers. I'm sure others have
quite different needs.
My hope is simply for Linux to be able to continue interoperating with
essentially everything. It is such a wonderful tool, especially for those
of us who don't have any old hardware lying around and who run
our favourite operating systems in emulation. I read the Phoronix kernel
warning regarding DECnet removal and was curious what other options were
out there and was concerned that there might be few or none. Getting
DECnet running natively on Linux is challenging even now, and I presume
this will soon become even more difficult unless alternate approaches are
found? Bringing up a VAX/VMS instance in SimH just to log into another
remote server can get a bit tedious and isn't always the most efficient or
responsive - but it always works... :) (I'm still sad about losing
my DECserver 90M)
I am hoping to eventually revisit some of the other systems from my past
such as RSTS/E, RSX and various flavours of ULTRIX, and as always, Linux
will be my portal. I find it fascinating that you mentioned Kermit. Long
long ago I wrote a DOS/Windows packet driver shim to allow many of the
early TCP/IP stacks including the one built into DOS Kermit to load on our
DEPCA card equipped PCs running Pathworks. This was long before Pathworks
directly supported TCP/IP. I suspect it's still available on what's left
of the Columbia Kermit archives... :)
F.Y.I: I have been using latd, latcp & llogin on Linux for some time and it
has been quite stable, but my use has been almost exclusively simple back
and forth terminal sessions between emulated VAX VMS systems and Linux.
Nothing particularly advanced.
On Tue, Aug 2, 2022 at 11:50 AM Thomas DeBellis <tommytimesharing(a)gmail.com>
wrote:
'Real' is an unfortunate word.
If by 'Real', you mean commercial applications that people pay money for,
then I wasn't aware of the DECnet market being very large. I'd love to be
contradicted on this...
That being said, I can truthfully say that if you are interested in
bullet-proof code, then the *best* thing you can do is a port to another
transport or platform and perform regression tests.
I had code that ran on DOS for years that I ported to the protected mode
under OS/2 1.3. This was more straightforward than it seems because the
Microsoft C version 5 C compiler did just about all of the work and most
assembler didn't need to change. Bugs came hurtling out because of edge
cases that bumped into segment limits now enforced by hardware. I replaced
malloc with direct calls to get exact segments sizes and more bugs showed
up. And it was faster than using banked memory, which surprised us.
I'm finishing a transport addition to Kermit to use Tops-10 and Tops-20
NRT's. Bugs have come flying out because of edge use cases and recovery
and it is now far more robust. This includes it being a TCP/IP client to
C-Kermit.
Same thing with MMAILR (SMTP) over DECnet.
Same thing with FTP over DECnet.
For hobbyist's some DEC OS's never came with a DEC sanctioned TCP/IP
stack. So if you don't have DECnet, you can't realistically talk to
Tops-10 and some others. Probably OS/8, *maybe* RSTS and whatever
version of RSX you have that Johnny has gotten to. Others?
Talking to these old operating systems has been a gold mine for finding
bugs in Tops-20, supporting CUSPs, Galaxy and DAP. This is nothing against
those programmers, they just weren't given the time to fully productize
some very interesting features.
I'd prefer to have DECnet in Linux for that reason. However, I don't
recall that I ever came across a very stable version of latd and the client
(whose name I've forgotten). Somebody on this list worked on them I think.
On 8/2/22 11:25 AM, Brian Angus wrote:
I like that idea, although I do wonder how many "real" applications would
really need, want, or even try to support DECnet directly in these
modern times? For the terminal server case that I am initially interested
in building, CTERM and a few network diagnostic tools would keep me very
satisfied, Adding in some file transfer capabilities would be simply
awesome.
It would be really useful even if some of these functions were only
exposed through internal PyDECnet sub-commands instead of being available
system-wide. I've been happily using PyDECnet for a couple of years, but I
haven't yet upgraded to your new test releases, and I haven't kept up on
what all is included in your future plans? Regardless, I suspect that any
somewhat easier way to keep a version of DECnet running on Linux with even
the minimal set of tools would be appreciated by many around here. How do
you think the performance would be with CTERM written in Python?
On Tue, Aug 2, 2022 at 10:46 AM Paul Koning <paulkoning(a)comcast.net>
wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
On Aug 2, 2022, at 10:40 AM, Brian Angus
<brian.angus(a)gmail.com> wrote:
Hello,
I'm not a programmer, at least not a very good one, and I'm quite happy
to
expose my ignorance in the effort to learn something new, so I was
wondering how real this dependency is on having Linux kernel support for
DECnet. We are quite able to put DECnet packets out on the wire using
various user mode processes such as with our favourite emulator SimH. I
currently run VAX DECnet on several linux boxes without any special or
unusual kernel shenanigans using a simple TAP ethernet driver. I also use
other non-IP based protocols such as LAT that do not require any special
kernel mode modules, drivers or privileges.
Wouldn't it be awesome if we could install a "simple" DECnet daemon on
Linux and tweak the few user mode commands that we still use to point to
that instead of the special kernel drivers that are needed today. This is
probably just wishful thinking, but a very simple non-kernel DECnet
implementation might help ensure its survival for a few more decades.
I could well be completely wrong, but I thought I would ask anyway.
What kernel support gives you is the ability to use the standard "socket"
kernel API to communicate using DECnet. User mode code means a different
API.
Now if Linux were to add a way to create a user-mode back end to sockets,
sort of like a socket analog to FUSE (file system in user mode), then you
could do DECnet in user mode and still get sockets.
Hm... SUSE? (Oh well, that acronym is taken...)
paul
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se