2 Aug
2022
2 Aug
'22
7:24 p.m.
You probably have a newer version than I do. What's your version?
llogin did work for awhile for me, but now all it does is exit with no
message whatsoever.
On 8/2/22 1:09 PM, Brian Angus wrote:
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 tohecnet-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
_______________________________________________
HECnet mailing list --hecnet(a)lists.dfupdate.se
To unsubscribe send an email tohecnet-leave(a)lists.dfupdate.se