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:
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
--
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