2 Aug
2022
2 Aug
'22
1:39 p.m.
Possibly already known, but just in case...
-------- Forwarded Message --------
Subject: [cctalk] DECnet to be dropped from Linux
Date: Tue, 2 Aug 2022 12:39:21 +0200
From: Liam Proven via cctalk <cctalk(a)classiccmp.org>
Reply-To: General Discussion: On-Topic and Off-Topic Posts <cctalk(a)classiccmp.org>
To: General Discussion: On-Topic and Off-Topic Posts <cctalk(a)classiccmp.org>
https://www.phoronix.com/news/Linux-DECnet-2022-Removal
https://lore.kernel.org/lkml/20220731190646.97039-1-stephen@networkplumber.…
--
Liam Proven ~ Profile: https://about.me/liamproven
Email: lproven(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
2 Aug
2 Aug
3:03 p.m.
Maybe someone on this mailing list can archive a working version
with the user-mode clients for the future?
-P
----- Original Message -----
From: "John H. Reinhardt"
<johnhreinhardt(a)thereinhardts.org>
To: "The Hobbyist DECnet mailing list" <hecnet(a)lists.dfupdate.se>
Sent: Tuesday, August 2, 2022 7:39:12 AM
Subject: [HECnet] Fwd: DECnet to be dropped from Linux
Possibly already known, but just in case...
3:37 p.m.
Should be no need.
kernel.org holds all copies of the Linux kernel source code since the first release. We
only need to note this point in time so that any future DECnet on Linux work uses a kernel
with the code still present.
Cheers, Wiz!!
Sent from my iPhone
On 2 Aug 2022, at 11:03 pm, Peter Lothberg <roll(a)stupi.com> wrote:
Maybe someone on this mailing list can archive a working version
with the user-mode clients for the future?
-P
----- Original Message -----
From: "John H. Reinhardt" <johnhreinhardt(a)thereinhardts.org>
To: "The Hobbyist DECnet mailing list" <hecnet(a)lists.dfupdate.se>
Sent: Tuesday, August 2, 2022 7:39:12 AM
Subject: [HECnet] Fwd: DECnet to be dropped from Linux
Possibly already known, but just in case...
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
4:40 p.m.
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.
I'm hoping to build a tiny terminal server for my vt520 on a Raspberry Pi
Zero to replace a lost DECserver 90M. I would love to have CTERM support
in addition to LAT, TELNET (and SSH) without having to go through miserable
linux kernel cross-compilation headaches... ;)
Cheers,
Brian
On Tue, Aug 2, 2022 at 9:37 AM David Moylan <djm(a)wiz.net.au> wrote:
Should be no need.
kernel.org holds all copies of the Linux kernel source code since the
first release. We only need to note this point in time so that any future
DECnet on Linux work uses a kernel with the code still present.
Cheers, Wiz!!
Sent from my iPhone
On 2 Aug 2022, at 11:03 pm, Peter Lothberg <roll(a)stupi.com> wrote:
Maybe someone on this mailing list can archive a working version
with the user-mode clients for the future?
-P
----- Original Message -----
From: "John H. Reinhardt" <johnhreinhardt(a)thereinhardts.org>
To: "The Hobbyist DECnet mailing list" <hecnet(a)lists.dfupdate.se>
Sent: Tuesday, August 2, 2022 7:39:12 AM
Subject: [HECnet] Fwd: DECnet to be dropped from Linux
Possibly already known, but just in case...
_______________________________________________
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
4:43 p.m.
Technically you could definitely do a user mode implementation. The
problem is all existing clients, servers and applications that are
already using an API to access DECnet that will not work with your
DECnet stack. But that's the only "problem".
And there could sometimes be degraded service and operation because user
level means you are also constrained by the normal process scheduling.
But it would mostly work just fine.
Johnny
On 2022-08-02 16:40, Brian Angus 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.
I'm hoping to build a tiny terminal server for my vt520 on a Raspberry
Pi Zero to replace a lost DECserver 90M. I would love to have CTERM
support in addition to LAT, TELNET (and SSH) without having to go
through miserable linux kernel cross-compilation headaches... ;)
Cheers,
Brian
On Tue, Aug 2, 2022 at 9:37 AM David Moylan <djm(a)wiz.net.au
<mailto:djm@wiz.net.au>> wrote:
Should be no need.
kernel.org <http://kernel.org> holds all copies of the Linux kernel
source code since the first release. We only need to note this point
in time so that any future DECnet on Linux work uses a kernel with
the code still present.
Cheers, Wiz!!
Sent from my iPhone
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2 Aug 2022, at 11:03 pm, Peter Lothberg
<roll(a)stupi.com
<mailto:roll@stupi.com>> wrote:
Maybe someone on this mailing list can archive a working version
with the user-mode clients for the future?
-P
----- Original Message -----
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
<mailto:hecnet@lists.dfupdate.se>
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se From: "John H. Reinhardt"
<johnhreinhardt(a)thereinhardts.org
<mailto:johnhreinhardt@thereinhardts.org>>
To: "The Hobbyist DECnet mailing list" <hecnet(a)lists.dfupdate.se
<mailto:hecnet@lists.dfupdate.se>>
Sent: Tuesday, August 2, 2022 7:39:12 AM
Subject: [HECnet] Fwd: DECnet to be dropped from Linux
Possibly already known, but just in case...
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
<mailto:hecnet@lists.dfupdate.se>
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se> 
4:45 p.m.
New subject: DECnet to be dropped from Linux
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
5:25 p.m.
New subject: DECnet to be dropped from Linux
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:
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
5:43 p.m.
New subject: DECnet to be dropped from Linux
On Aug 2, 2022, at 11:25 AM, Brian Angus
<brian.angus(a)gmail.com> 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.
The latest (T1.1) has basic DAP support. I should do a V1.1 release; it's been long
enough to leave beta stage.
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?
Cterm in Python should be fine. It's been on my "to do at some point" list
for a while now. The main difficulty is that Cterm is a large and complicated protocol.
The earlier "RMterm" suite of protocols (it's really four, wrapped in a
single object number) would be a good first step. For one thing, most systems support it,
and a few like RSTS support nothing else.
PyDECnet T1.1 has a new program API, and this generation is finally sane and clean enough
to be readily useable. I created a pair of Python wrappers for it that are vaguely
socket-like. It would not be hard to do a C API library but that hasn't been done
yet. The API is documented in the "doc" subdirectory, take a look.
As for future plans, I don't have any specific ones listed right now. I can think of
a couple. More applications -- make sure DAP is complete enough, perhaps mail, remote
terminal, even more obscure ones like DTR and Netcpy.
A more ambitious effort would be Phase V...
paul
7:22 p.m.
New subject: DECnet to be dropped from Linux
Do you have a pointer anywhere for the "RMterm" suite of protocols? I
only have documentation for CTerm and LAT, plus some reverse engineering
that Johnny and I did on various flavors of NRT for Tops-10/20, RSX and
I think something else, maybe RSTS.
On 8/2/22 11:43 AM, Paul Koning wrote:
The earlier "RMterm" suite of protocols
(it's really four, wrapped in a single object number) would be a good first step.
7:32 p.m.
New subject: DECnet to be dropped from Linux
On Aug 2, 2022, at 1:22 PM, Thomas DeBellis
<tommytimesharing(a)gmail.com> wrote:
Do you have a pointer anywhere for the "RMterm" suite of protocols? I only
have documentation for CTerm and LAT, plus some reverse engineering that Johnny and I did
on various flavors of NRT for Tops-10/20, RSX and I think something else, maybe RSTS.
Look in the PyDECnet Subversion repository, the T1.1 branch:
svn://akdesign.dyndns.org/pydecnet/branches/t1.1/pydecnet
In the doc/protocols subdirectory are a couple of protocol documents reverse engineered
from running code or other unofficial sources. The remote terminal protocols are in
remote-terminal.txt.
paul
7:37 p.m.
New subject: DECnet to be dropped from Linux
My tech world is in a somewhat discombobulated state right now, but I
believe it is "latd v1.35". Regardless, it is just the standard "sudo apt
install latd" from the vanilla Raspberry Pi OS repositories.
On Tue, Aug 2, 2022 at 1:32 PM Paul Koning <paulkoning(a)comcast.net> wrote:
On Aug 2, 2022, at 1:22 PM, Thomas DeBellis
<tommytimesharing(a)gmail.com>
wrote:
Do you have a pointer anywhere for the "RMterm" suite of protocols? I
only have documentation for CTerm and LAT, plus some reverse engineering
that Johnny and I did on various flavors of NRT for Tops-10/20, RSX and I
think something else, maybe RSTS.
Look in the PyDECnet Subversion repository, the T1.1 branch:
svn://akdesign.dyndns.org/pydecnet/branches/t1.1/pydecnet
In the doc/protocols subdirectory are a couple of protocol documents
reverse engineered from running code or other unofficial sources. The
remote terminal protocols are in remote-terminal.txt.
paul
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
10:50 p.m.
New subject: DECnet to be dropped from Linux
Should have been RSTS/E, since RSX comes with the client side
applications for connecting to TOPS-20, RSTS/E, RSX and VMS.
I think the TOPS-20 variant was also what worked to Tops-10.
Johnny
On 2022-08-02 19:22, Thomas DeBellis wrote:
Do you have a pointer anywhere for the
"RMterm" suite of protocols? I
only have documentation for CTerm and LAT, plus some reverse engineering
that Johnny and I did on various flavors of NRT for Tops-10/20, RSX and
I think something else, maybe RSTS.
On 8/2/22 11:43 AM, Paul Koning wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
The earlier "RMterm" suite of protocols
(it's really four, wrapped in
a single object number) would be a good first step.
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
3 Aug
3 Aug
12:04 a.m.
New subject: DECnet to be dropped from Linux
You are correct about the 36 bit NRT servers.
The Tops-10 and Tops-20 variants are similar enough so that I only have
to check one byte in the configuration message; you'll recall that very
nice sheet you sent me with some notes about all this. What's puzzling
is that the operating system numbers are not the same between RMterm and
DAP.
Once that configuration check is done, there is absolutely no code
whatsoever in (my largely rewritten) sethost, Kermit-20 or TELNET which
pays any further attention. No special casing at all.
Actually, I don't think it's possible to directly tell the difference
after configuration although you might be able to deduce something from
information about the connection. There is no external or meta-data to
parse. Finally, if you try to do something 'clever' like send a DECnet
interrupt message on an NRT, you will irrevocably hang the session. At
least I did. It's on my list of things to look at.
On 8/2/22 4:50 PM, Johnny Billquist wrote:
Should have been RSTS/E, since RSX comes with the
client side
applications for connecting to TOPS-20, RSTS/E, RSX and VMS.
I think the TOPS-20 variant was also what worked to Tops-10.
Johnny
On 2022-08-02 19:22, Thomas DeBellis wrote:
Do you have a pointer anywhere for the
"RMterm" suite of protocols?
I only have documentation for CTerm and LAT, plus some reverse
engineering that Johnny and I did on various flavors of NRT for
Tops-10/20, RSX and I think something else, maybe RSTS.
On 8/2/22 11:43 AM, Paul Koning wrote:
The earlier "RMterm" suite of protocols
(it's really four, wrapped
in a single object number) would be a good first step.
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
2 Aug
2 Aug
10:36 p.m.
New subject: DECnet to be dropped from Linux
On 2022-08-02 17:43, Paul Koning wrote:
You should. :-)
CTERM is way complex, yes. Not something I'd recommend people to work on
general, but I know that you can probably sort it out, Paul. But do you
want to?
The various remote terminal protocols using object 23 is probably much
easier, but there you do have to do some clever things to figure out
what the remote system is, and then it's different protocols...
On Aug 2, 2022, at 11:25 AM, Brian Angus
<brian.angus(a)gmail.com> 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.
The latest (T1.1) has basic DAP support. I should do a V1.1 release; it's been long
enough to leave beta stage. 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?
Cterm in Python should be fine. It's been on my "to do at some point" list
for a while now. The main difficulty is that Cterm is a large and complicated protocol.
The earlier "RMterm" suite of protocols (it's really four, wrapped in a
single object number) would be a good first step. For one thing, most systems support it,
and a few like RSTS support nothing else. As for future plans, I don't have any specific
ones listed right now. I can think of a couple. More applications -- make sure DAP is
complete enough, perhaps mail, remote terminal, even more obscure ones like DTR and
Netcpy.
May I make a wish for NTDEMO? It's a protocol only RSX speaks right now,
but it's a really nice tool to get some insight into performance of
remote systems. I can help work out the protocol if needed.
DTR? Client then, I assume? Or do you plan to hook up to some database
engine and play server side as well?
But yes, DAP, both server and client, are pretty useful...
A more ambitious effort would be Phase V...
Ack. Pfft. No. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
10:43 p.m.
New subject: DECnet to be dropped from Linux
On Aug 2, 2022, at 4:36 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2022-08-02 17:43, Paul Koning wrote:
You should. :-)
CTERM is way complex, yes. Not something I'd recommend people to work on general, but
I know that you can probably sort it out, Paul. But do you want to?
Probably not. Cterm is not actually any better than what it replaced; the underlying
notion was to create a framework for other modes (like forms and editing). If that had
actually happened the protocol would have some redeeming features, but it didn't.
The main good thing Cterm ever did was prompt the creation of LAT (because Cterm, running
on an F-11 based comm server, was such a horribly sucking performer that it was obviously
not fit to ship, and something else was urgently needed).
On Aug 2,
2022, at 11:25 AM, Brian Angus <brian.angus(a)gmail.com> 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.
The latest (T1.1) has basic DAP support. I should do a
V1.1 release; it's been long enough to leave beta stage. 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?
Cterm in Python should be
fine. It's been on my "to do at some point" list for a while now. The main
difficulty is that Cterm is a large and complicated protocol. The earlier
"RMterm" suite of protocols (it's really four, wrapped in a single object
number) would be a good first step. For one thing, most systems support it, and a few
like RSTS support nothing else. The various remote terminal protocols using object 23
is probably much easier, but there you do have to do some clever things to figure out what
the remote system is, and then it's different protocols...
Actually, that part is easy. It starts with a "config" message exchange, and
that says which protocol to run. So the client connects, looks at the config response,
and branches off to one of four engines. It's simple enough even RSTS can do it.
:-)
As for future
plans, I don't have any specific ones listed right now. I can think of a couple.
More applications -- make sure DAP is complete enough, perhaps mail, remote terminal, even
more obscure ones like DTR and Netcpy.
May I make a wish for NTDEMO? It's a protocol only RSX speaks right now, but it's
a really nice tool to get some insight into performance of remote systems. I can help work
out the protocol if needed. DTR? Client then, I assume? Or do you plan to hook up
to some database engine and play server side as well?
Oops, ambiguous TLA. I meant DTR the test data receiver -- half of the "dtsend"
and "dtreceive" pair.
But yes, DAP, both server and client, are pretty
useful...
I have them in T1.1, at least as a start. Not quite solid yet but some of the basic
operations work.
paul
11:02 p.m.
New subject: DECnet to be dropped from Linux
On 2022-08-02 22:43, Paul Koning wrote:
I can sortof understand what they tried to do. It's just that it's not a
good idea anyway. That offloading to the remote system makes it way too
complex.
I know it's not too hard. Just needs to be done. In the RSX
distribution, they are four different programs which share some code
between them, but each just do one protocol. But they do detect if the
remote speaks another variant, and refuses to continue in that case.
Maybe something for me to poke at one day. Unifying four programs into
one... :-)
I hadn't heard of that. You might send me some more info, off line if preferred.
Probably better doing that offline. But if you log into MIM, you can try
running it and see. Just NTD to look at the local node, or NTD <host> if
you want to look at a remote node.
? to get some interactive help.
Oh. :-) Makes more sense. :-D
Actually, I realized that the DTR server side is called DDM, at least in
RSX. Object 30. If you have a client, you can query the DECnet nodename
database on MIM using it. ;-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Aug 2, 2022, at 4:36 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2022-08-02 17:43, Paul Koning wrote:
Probably not. Cterm is not actually any better than what it replaced; the underlying
notion was to create a framework for other modes (like forms and editing). If that had
actually happened the protocol would have some redeeming features, but it didn't.
Cterm in Python should be fine. It's been on
my "to do at some point" list for a while now. The main difficulty is that
Cterm is a large and complicated protocol. The earlier "RMterm" suite of
protocols (it's really four, wrapped in a single object number) would be a good first
step. For one thing, most systems support it, and a few like RSTS support nothing else.
CTERM is way complex, yes. Not something I'd recommend people to work on general, but
I know that you can probably sort it out, Paul. But do you want to? The main good thing Cterm ever did was prompt the
creation of LAT (because Cterm, running on an F-11 based comm server, was such a horribly
sucking performer that it was obviously not fit to ship, and something else was urgently
needed).
:-)
The various
remote terminal protocols using object 23 is probably much easier, but there you do have
to do some clever things to figure out what the remote system is, and then it's
different protocols...
Actually, that part is easy. It starts with a "config" message exchange, and
that says which protocol to run. So the client connects, looks at the config response,
and branches off to one of four engines. It's simple enough even RSTS can do it. :-)
As for future plans, I don't have any specific
ones listed right now. I can think of a couple. More applications -- make sure DAP is
complete enough, perhaps mail, remote terminal, even more obscure ones like DTR and
Netcpy.
May I make a wish for NTDEMO? It's a protocol only RSX speaks right now, but it's
a really nice tool to get some insight into performance of remote systems. I can help work
out the protocol if needed. DTR? Client
then, I assume? Or do you plan to hook up to some database engine and play server side as
well?
Oops, ambiguous TLA. I meant DTR the test data receiver -- half of the
"dtsend" and "dtreceive" pair.
5:49 p.m.
New subject: DECnet to be dropped from Linux
'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:
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
7:09 p.m.
New subject: DECnet to be dropped from Linux
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
7:24 p.m.
New subject: DECnet to be dropped from Linux
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
10:51 p.m.
New subject: DECnet to be dropped from Linux
I doubt he have any newer, better working version. The Linux LAT
implementation is buggy, and I've never seen/heard of anyone else fixing
it. And the problem there too is that it was reverse engineered and
tested just against VMS. I assume/guess that with VMS it works
acceptably well. With RSX it do not work well at all. Never have.
Johnny
On 2022-08-02 19:24, Thomas DeBellis wrote:
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:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
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:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se 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 
10:20 p.m.
New subject: DECnet to be dropped from Linux
On Aug 2, 2022, at 11:49 AM, Thomas DeBellis
<tommytimesharing(a)gmail.com> wrote:
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.
I had been maintaining a DECnet repository with a number of bug fixes at both the
application and kernel level (<https:://github.com/JohnForecast/RaspbianDECnet
<http://github.com/JohnForecast/RaspbianDECnet>>). It’s mostly targeted at the
Raspberry Pi but I have tested an earlier version of the code with vanilla Debian on x86
(both 32- and 64-bit). Unfortunately, due to family medical issues, I’ve been unable to
spend any time on this (or any other) project for the last 9 months, and I don't see
that changing in the foreseeable future.
John.
10:44 p.m.
New subject: DECnet to be dropped from Linux
On 2022-08-02 17:49, Thomas DeBellis 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...
I think there was a fair number of applications once upon a time. All
gone, and have been gone quite a while now. Rewind more than 30 years
for that one...
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?
The only OSes with a DEC sanctioned TCP/IP in addition to DECnet would
be TOPS-20, VMS and Ultrix.
DECnet only would be OS/8, RT-11, RSTS/E, RSX and Tops-10, I think.
Of course, TCP/IP do exist for both RT-11 and RSX. But not from DEC.
KERMIT is always another option if wanting to talk to systems...
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.
DECnet for Linux was ever only reverse engineered and tested against
VMS. It can act funny against other OSes.
LAT have one serious bug that I've fixed. But I've not distributed my
fix to anyone. I know, I should. But it's not been high on my priority
list, and I don't even know who to contact about it.
Running the Linux LAT against at least RSX never works for very long
before it stops and aborts.
I haven't tried any other OSes, so it might be more or less of a problem
on different OSes depending on their side as well, but Linux LAT are
mismanaging credits leading to flow control errors.
I guess if anyone here is interested, I can always just send a diff for
the fix(es). And others can apply it and recompile...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
3 Aug
3 Aug
12:39 a.m.
New subject: DECnet to be dropped from Linux
I have a bit of work to do before reconstructing my little environment, but
I would like to try out your fixes for the "latd" package. A pointer to
your patches would be greatly appreciated. No urgency but I should
eventually be able to do some testing on several different arm and x86
architecture machines.
On Tue, Aug 2, 2022 at 4:44 PM Johnny Billquist <bqt(a)softjar.se> wrote:
I guess if anyone here is interested, I can always just send a diff for
the fix(es). And others can apply it and recompile...
Johnny
10:05 a.m.
New subject: DECnet to be dropped from Linux
Ok, here is the patch. Let me know if there are any problems. I've been
mainly testing and playing with this under OSX, but the changes I made
should really make no difference for the generic building/installing/using.
Changed the version number to 1.36 as well.
Johnny
On 2022-08-03 00:39, Brian Angus wrote:
I have a bit of work to do before reconstructing my
little environment,
but I would like to try out your fixes for the "latd" package. A
pointer to your patches would be greatly appreciated. No urgency but I
should eventually be able to do some testing on several different arm
and x86 architecture machines.
On Tue, Aug 2, 2022 at 4:44 PM Johnny Billquist <bqt(a)softjar.se
<mailto:bqt@softjar.se>> wrote:
I guess if anyone here is interested, I can always just send a diff for
the fix(es). And others can apply it and recompile...
Johnny
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
2 Aug
2 Aug
10:29 p.m.
New subject: DECnet to be dropped from Linux
I would suspect the only applications that exist, and people still see,
are all the standard DECnet utilities. But that's a whole bunch of
programs, so it would be quite an effort to rewrite all of it to use
some other API.
Johnny
On 2022-08-02 17:25, 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
<mailto:paulkoning@comcast.net>> wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Aug 2, 2022, at 10:40 AM, Brian Angus
<brian.angus(a)gmail.com
<mailto:brian.angus@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
<mailto:hecnet@lists.dfupdate.se>
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
10:38 p.m.
New subject: DECnet to be dropped from Linux
Agreed. The interesting possibility is an API library that is sufficiently close to the
Linux API that applications can work with just a recompile. I don't know if
that's doable; I haven't looked at the Linux API in decades.
For that matter, there's also the DEC Unix API, about which I'm equally ignorant.
Obviously, another possibility would be for someone else to do what I just described. The
PyDECnet API (in T1.1) is I think pretty straightforward and easy to use; roughly speaking
it does what the Session Control spec says a generic API would look like. The
communication mechanism to the running DECnet code is a Unix domain streaming mode
connection carrying JSON encoded requests and responses, full duplex both ways.
That's what the Python API wrappers talk to. Those wrappers are simple and so is
using them; in T1.1 there are several applications (PMR, NFT) that show this.
paul
On Aug 2, 2022, at 4:29 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
I would suspect the only applications that exist, and people still see, are all the
standard DECnet utilities. But that's a whole bunch of programs, so it would be quite
an effort to rewrite all of it to use some other API.
Johnny
On 2022-08-02 17:25, 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
<mailto:paulkoning@comcast.net>> wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
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
<mailto:brian.angus@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
<mailto:hecnet@lists.dfupdate.se>
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
10:54 p.m.
New subject: DECnet to be dropped from Linux
I *think* the Linux DECnet API fairly closely resembles the Ultrix one.
Not sure if they would be source code compatible, but that would be a
nice touch.
Johnny
On 2022-08-02 22:38, Paul Koning wrote:
Agreed. The interesting possibility is an API library
that is sufficiently close to the Linux API that applications can work with just a
recompile. I don't know if that's doable; I haven't looked at the Linux API
in decades.
For that matter, there's also the DEC Unix API, about which I'm equally
ignorant.
Obviously, another possibility would be for someone else to do what I just described.
The PyDECnet API (in T1.1) is I think pretty straightforward and easy to use; roughly
speaking it does what the Session Control spec says a generic API would look like. The
communication mechanism to the running DECnet code is a Unix domain streaming mode
connection carrying JSON encoded requests and responses, full duplex both ways.
That's what the Python API wrappers talk to. Those wrappers are simple and so is
using them; in T1.1 there are several applications (PMR, NFT) that show this.
paul
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Aug 2, 2022, at 4:29 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
I would suspect the only applications that exist, and people still see, are all the
standard DECnet utilities. But that's a whole bunch of programs, so it would be quite
an effort to rewrite all of it to use some other API.
Johnny
On 2022-08-02 17:25, Brian Angus wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se 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
<mailto:paulkoning@comcast.net>> wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
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
<mailto:brian.angus@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
<mailto:hecnet@lists.dfupdate.se>
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
642
days inactive
643
days old
26 comments
8 participants
participants (8)
-
Brian Angus -
David Moylan -
John Forecast -
John H. Reinhardt -
Johnny Billquist -
Paul Koning -
Peter Lothberg -
Thomas DeBellis