Jordi Guillaumes i Pons
Barcelona - Catalunya - Europa
El 07/06/2012, a les 14:23, Johnny Billquist <bqt at softjar.se> va escriure:
On 2012-06-07 12:42, Dave McGuire wrote:
On 06/07/2012 06:37 AM, Sampsa Laine wrote:
Howabout starting it as a daemon (running as root) via the boot
scripts, and have non-root users's programs access it via a
socket?
Cool idea - you could even have multiple hosts connect this way but
export one DECNET endpoint, i.e. run CTERM on Box A whilst FAL goes
to Box B, and MAIL to Box C :)
Yes, you could multiplex/demultiplex it any way you wanted. It would
open up all sorts of interesting configuration possibilities.
I think it would help if you actually explained a little more what you actually want to accomplish, and what you see as the problems...?
If I've understood it correctly, the idea is to replace the (dying) kernel support for DECNet under linux by userland code, so it the current module dies definitely due to kernel ABI changes we could still use decnet in the Linux boxes.
The process separation and distributed tasks are just a proposed improvement over the initial idea.
I'd add as an additional benefit that moving decnet out of the kernel would make possible to port it to other unix flavours, like the BSDs and Mac OSX.
Johnny
Jordi Guillaumes i Pons
Barcelona - Catalunya - Europa
El 07/06/2012, a les 13:46, Dave McGuire <mcguire at neurotica.com> va escriure:
On 06/07/2012 07:26 AM, Jordi Guillaumes i Pons wrote:
According to this:
http://h71000.www7.hp.com/openvms/os/openvms-release-history.html
Support for the 4000/90 came in version 5.5-2 (1992). The 3300 was
supported in 5.0-2 and the 4000 mod. 2000 in 5.4-2. So none of my real
boxen can run 4.7.
Well you've gotta find yourself some more machines! 11/750s are
probably the most common of the 4.x-capable machines, though there don't
seem to be many left floating around.
Heh, then I would have to find also a new home and probably an attorney to handle de divorce demand ;)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 2012-06-07 14:22, Johnny Billquist wrote:
On 2012-06-07 12:37, Sampsa Laine wrote:
On 7 Jun 2012, at 11:29, Dave McGuire wrote:
Howabout starting it as a daemon (running as root) via the boot
scripts, and have non-root users's programs access it via a socket?
Cool idea - you could even have multiple hosts connect this way but
export one DECNET endpoint, i.e. run CTERM on Box A whilst FAL goes to
Box B, and MAIL to Box C :)
Are you trying to suggest something like NAT for DECnet?
I'm not sure how easy that would be to do in DECnet, as it works in some
different ways than IP that might cause problems doing this.
Reading through things a little more...
Are you actually talking now about implementing a DECnet stack on a machine in user mode?
That is definitely not doable. You need atleast one part that talks raw ethernet, if you want access to the local ethernet. And that part needs to run as root. No way around that.
Normal user programs should of course not need to be running as root, nor much around in the kernel, but there is nothing tricky about this. The DECnet stack is one process. Any other program talking DECnet needs to talk to the DECnet stack. That can be done in a number of ways. Unix sockets, TCP/IP sockets, shared memory, named pipes... Just pick something.
The ugly part is that you'll need to write all the software to handle all the protocols that sits on top of DECnet, such as a FAL listener, a FAL user client, CTERM listener and client, NICE, PHONE, MAIL... The list goes on...
You'll probably want to write a library with all the DECnet library primitives so that you have a nice API for the user level code to use. If you are lucky, the API in the current implementation can be adapted to your new implementation, which will make it possible to reuse a lot of code. I have not looked at how the current DECnet API looks like in Linux.
Anyway, this is a different story than any potential problems with promiscuous mode...
And you still need to be root to play with ethernet.
Johnny
It's worth stating that both Sampsa and I (at least) have a good deal of software sitting on our servers for VAXen running VMS.
My AlphaServer is still up and down at the moment as local usage dictates. I still need to get round to that squid cache...
Mark.
Sent from my iPad
On 7 Jun 2012, at 11:48, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> wrote:
Al 07/06/12 12:11, En/na hvlems at zonnet.nl ha escrit:
Jordi,
You wrote that the NIC on the 4000-90 was broken. Did you try an external transceiver on the AUI connector (there's a switch on the back).
An Alllied Telesys or DEC transceiver might solve the issue. The logic that drives the BNC connector is on a separate module IIRC.
I didn't. Actually, I thought you needed a thickwire segment to use a transceiver and a drop cable. I should have researched it better. Any idea of the DEC name for that thinwire transceiver? (Or a compabtible one). Anyways, I think I canibalized that machine a little bit, so I'm not sure what is actually inside of the inclosure. It looks like a nice summer vacation project :)
If you need software kits for the VAX, post your needs. If I have the kit(s) I'll burn them on a CD. Hans
Oh, thanks. As I said, I've plenty of "modern" stuff, but I miss some of the older software I used back in those days (pre-5.0), a (call it nostalgia) I'm quite trying to reproduce that first environment I worked on. Right now, I miss:
- FMS
- TDMS
- VAX BASIC
- LSE
That's pretty all. I also used AI1 (the dreaded office package) but I'm not sure I'll want to fight that monster again ;). No need to burn a CD, we could arrange the transfer by network (HECnet or regular internet). I understand the use of that stuff is covered by the hobbyist license (not sure about TDMS though), so we would not do anything out of the law.
On 2012-06-07 12:42, Dave McGuire wrote:
On 06/07/2012 06:37 AM, Sampsa Laine wrote:
Howabout starting it as a daemon (running as root) via the boot
scripts, and have non-root users's programs access it via a
socket?
Cool idea - you could even have multiple hosts connect this way but
export one DECNET endpoint, i.e. run CTERM on Box A whilst FAL goes
to Box B, and MAIL to Box C :)
Yes, you could multiplex/demultiplex it any way you wanted. It would
open up all sorts of interesting configuration possibilities.
I think it would help if you actually explained a little more what you actually want to accomplish, and what you see as the problems...?
Johnny
Mark,
I've run a 4000/60 and 4000/90 at different times.
The '60s are about 12 VPUs and the '90s are about 40 VPUs. However, both numbers are quite respectable and I've found that having a reasonable amount of memory (64MB+) enables both to be quite competent. Expect to wait about 3 times as long for CPU intensive tasks to complete on the '60.
Most of time however you don't really notice much difference.
Regards, Mark.
Sent from my iPad
On 7 Jun 2012, at 12:41, Mark Benson <md.benson at gmail.com> wrote:
On 7 Jun 2012, at 10:33, Jordi Guillaumes i Pons
<jg at jordi.guillaumes.name> wrote:
Hello list,
I've just joined HECnet under the area 7, and I wanted to introduce myself and my little puppies :)
Hello!
I am interested to know how you find the performance of the VAXstation
4000/60 compared to others.
Good to see someone with such great skills on old iron join us. I know
very little outside vasics and simple DECnet setup :)
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
On 2012-06-07 12:37, Sampsa Laine wrote:
On 7 Jun 2012, at 11:29, Dave McGuire wrote:
Howabout starting it as a daemon (running as root) via the boot
scripts, and have non-root users's programs access it via a socket?
Cool idea - you could even have multiple hosts connect this way but export one DECNET endpoint, i.e. run CTERM on Box A whilst FAL goes to Box B, and MAIL to Box C :)
Are you trying to suggest something like NAT for DECnet?
I'm not sure how easy that would be to do in DECnet, as it works in some different ways than IP that might cause problems doing this.
Johnny
On 2012-06-07 12:29, Dave McGuire wrote:
On 06/07/2012 06:24 AM, Mark Benson wrote:
So we agree security is a storm in an espresso cup.
Well put. :)
If you farm it out to a low cost dedicated device it's not costing you
CPU cycles on your work computer.
MAC address spoofing gets around the issue of source MAC address from
a DECnet stack.
pcap gets around finding incoming packets that are fror your DECnet stack.
What issues remain that stop you using a non-kernel solution?
My only concern now is if the stack has to run as root how do
non-privileged ysers use it?
Howabout starting it as a daemon (running as root) via the boot
scripts, and have non-root users's programs access it via a socket?
Now you all got me confused again. What are you trying to do/solve here?
Are you trying to devise a way for normal users to talk raw ethernet??? Why?
Or are you just trying to figure out how a non-root user can start the bridge (or router) program? Why would they do that? And why would this not be started at boot time? Also, why, if you absolutely insist that normal users should start this at random time, would not suid suffice?
Johnny
Hi,
Regarding transceivers I've always used CentreCOM 210T Twisted Pair Transceivers on the AUI ports of my VS4000/60,90 and VLC.
An ebay search should land you one for a few quid/dollars.
Regarding the VS3100 - I have a load in my garage, so if you need spares I can strip bits out of one as required.
Regards, Mark.
Sent from my iPad
On 7 Jun 2012, at 11:48, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> wrote:
Al 07/06/12 12:11, En/na hvlems at zonnet.nl ha escrit:
Jordi,
You wrote that the NIC on the 4000-90 was broken. Did you try an external transceiver on the AUI connector (there's a switch on the back).
An Alllied Telesys or DEC transceiver might solve the issue. The logic that drives the BNC connector is on a separate module IIRC.
I didn't. Actually, I thought you needed a thickwire segment to use a transceiver and a drop cable. I should have researched it better. Any idea of the DEC name for that thinwire transceiver? (Or a compabtible one). Anyways, I think I canibalized that machine a little bit, so I'm not sure what is actually inside of the inclosure. It looks like a nice summer vacation project :)
If you need software kits for the VAX, post your needs. If I have the kit(s) I'll burn them on a CD. Hans
Oh, thanks. As I said, I've plenty of "modern" stuff, but I miss some of the older software I used back in those days (pre-5.0), a (call it nostalgia) I'm quite trying to reproduce that first environment I worked on. Right now, I miss:
- FMS
- TDMS
- VAX BASIC
- LSE
That's pretty all. I also used AI1 (the dreaded office package) but I'm not sure I'll want to fight that monster again ;). No need to burn a CD, we could arrange the transfer by network (HECnet or regular internet). I understand the use of that stuff is covered by the hobbyist license (not sure about TDMS though), so we would not do anything out of the law.
On 2012-06-07 12:02, Mark Benson wrote:
On 7 Jun 2012, at 10:32, Dave McGuire<mcguire at neurotica.com> wrote:
On 06/07/2012 05:09 AM, Johnny Billquist wrote:
Indeed. In addition to the fact that I'm not clear what security threat
we're talking about here...
I'm not convinced at all that there's any sort of security issue here.
It is marginally less secure based on thus:
Any OS can be violated to provide root access. In normal circumstances
the ethernet interface does not expose other packets. On a system
running with the interface in promiscuous mode it does expose other
packets. Thus if the system's security is breached (i.e. the box is
rooted) it exposes more than the normal level of information about
your network without the perpetrator needing to act (i.e. run a
scanner of their own) to get it.
Any program that needs access to raw ethernet packets needs to run as root. Promiscuous mode or not. Promiscuous mode itself has little to do with this.
So if you want to run anything like a bridge or a router, you will need to run it as root. Promiscuous mode is basically just allowing you to share the same interface as the system is otherwise using, instead of having to dedicate a separate ethernet interface for this. Still needs to run as root. With a separate interface you can skip promiscuous mode, since you can change the MAC address to the "right" one instead.
Like I said it's minimal. If your box gets rooted you are screwed anyway ;)
Indeed. And it has nothing to do with promiscuous mode. It has everything to do with running something as root, which is required if you ever want to talk ethernet.
But if someone gains access as root to the machine, then what the bridge program is doing is totally irrelevant, since as root, you can do much more, much easier, than trying to corrupt the bridge. You might as well just run your own bridge-like program...
Johnny
On Thu, 7 Jun 2012, Sampsa Laine wrote:
Speaking of old software, does anybody happen to have WordPerfect for VMS lying around?
Hi Sampsa,
If Dave comes through and finds you an image of WP for VMS, please let me know as I'd love to have a copy too. :) I used to in my younger days know all those key sequences by heart and it would be interesting to see how much I remember.
Thanks,
Fred
On 2012-06-07 11:54, Mark Benson wrote:
On 7 Jun 2012, at 10:09, Johnny Billquist<bqt at softjar.se> wrote:
Yeah, I'm also starting to wonder if we're talking about different things...
I wouldn't be surprised if I am totally across-purposes as I am just a
user with a little knowledge (and we all know about a little
knowledge?) in this argument.
If nothing else, having the discussion will clear things up, and we all can learn something...
Maybe someone can explain to me the worries they have with this "wide open" thing, and how that improves by having the bridge (or router) running on a separate machine?
As far as I see it, using pcap and promiscuous mode creates 2 potential issues:
Security is possibly compromised, but promiscuous mode is only
activated as root so rhis isn't a big concern.
I can't see how it is a problem at all. If you are root, you have already compromised the system 100%. There is nothing more to say. Being able to sniff the network by setting your device to promiscuous mode is not increasing the compromise when you are already root. There is basically nothing you can't do when you are root. That is already the ultimate security issue.
So no, I can't see how promiscuous mode increase the security concerns.
There is an increase in traffic and filtering loads on the CPU because
the LAN interface is no longer filtering packets in hardware.
Right. However, since I would expect close to no one have network without switches nowadays, in reality you are not getting any packets that are filtered by the hardware in the machine anyway, so this is for most people really a non-difference.
Using a separate 'appliance' to do the work presents these possible solutions:
There is nothing of import on the appliance so immediate security is
not a problem. Packets from or intended for other destinations can
still be sniffed but you still need root access to the device.
And if you have root, then promiscuous mode is already available to you. That the bridge (or router) needs it is not increasing the exposure.
Traffic through the device and using the CPU to filter it is the
intended purpose of the 'appliance' thus it is not invading your other
tasks on a user-centric machine and it is also not compromised by
other heavy tasks absorbing CPU cycles for other things.
Right. But see above... Not to mention the fact that even your user-facing machines are most likely just burning CPU-cycles in the OS idle loop...
Indeed. In addition to the fact that I'm not clear what security threat we're talking about here...
It's minimal, but it shouldn't be totally ignored unless it's an
acceptable risk to the users concerned. Usual security caveats apply
i.e. use good passwords on the router device etc.
I'm still totally failing to see the security issues here.
Note that the bridge (or router) software running does not even open up much of an access path to the machine it's running on. You could possibly exploit bugs, but it needs to come through the normal traffic paths.
It's just anal-retentive perfectionism, nothing more, no REAL impact,
no REAL casualties...but it makes me sleep better at night, and I can
usually achieve it pretty much everywhere else. :)
No objections to that one. Except I don't loose sleep over a few CPU cycles here, since they are pretty much zero anyway. But like I said before, I don't mind clean stuff.
Again, shut it in a small box on it's own with a single-purpose OS and
it becomes a clean(er) solution.
Yes. Cleaner. Not safer.
Johnny
I was still running 4.7 on one machine (11/750) when I installed my
first 3100. I'm pretty sure I installed 5.0 on the 3100 though. I was
already running 5.0 on a pair of MicroVAX-3600s, and then 5.1 came out
very shortly thereafter.
I vaguely remember a few VAX 2000 machines booting 4.7 from an 11/780.
Is there an installable copy of 4.7 available anywhere that I could try on
one of my VS2000's? Perhaps it might improve performance over 5.5-2 which they
currently run.
Regards,
Peter Coghlan.
On 06/07/2012 07:26 AM, Jordi Guillaumes i Pons wrote:
According to this:
http://h71000.www7.hp.com/openvms/os/openvms-release-history.html
Support for the 4000/90 came in version 5.5-2 (1992). The 3300 was
supported in 5.0-2 and the 4000 mod. 2000 in 5.4-2. So none of my real
boxen can run 4.7.
Well you've gotta find yourself some more machines! 11/750s are
probably the most common of the 4.x-capable machines, though there don't
seem to be many left floating around.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 7 Jun 2012, at 10:33, Jordi Guillaumes i Pons
<jg at jordi.guillaumes.name> wrote:
Hello list,
I've just joined HECnet under the area 7, and I wanted to introduce myself and my little puppies :)
Hello!
I am interested to know how you find the performance of the VAXstation
4000/60 compared to others.
Good to see someone with such great skills on old iron join us. I know
very little outside vasics and simple DECnet setup :)
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
Al 07/06/12 13:14, En/na Dave McGuire ha escrit:
I bet 4.7 would absolutely scream on a 4000-90 if it had CPU support. The difference between 4.7 and 5.0 on a 2.8VUP MicroVAX-III is like night and day...I can only imagine it on a 4000-90, more than ten times faster! -Dave
According to this:
http://h71000.www7.hp.com/openvms/os/openvms-release-history.html
Support for the 4000/90 came in version 5.5-2 (1992). The 3300 was supported in 5.0-2 and the 4000 mod. 2000 in 5.4-2. So none of my real boxen can run 4.7.
On 06/07/2012 07:10 AM, Jordi Guillaumes i Pons wrote:
Will pre-5.0 VMS run on a 4000-90? I don't recall when NVAX CPU
support was added to VMS.
I don't think so. I've built a 4.7 system running in a 11-780 SIMH
emulator :) I doubt 4.7 would run even in my 3300 (my oldest real machine).
I was still running 4.7 on one machine (11/750) when I installed my
first 3100. I'm pretty sure I installed 5.0 on the 3100 though. I was
already running 5.0 on a pair of MicroVAX-3600s, and then 5.1 came out
very shortly thereafter.
BTW, 4.7 boots so fast under SIMH than at first I thought it had somehow
crashed or hung. When I got the "username:" prompt after pressing return
I was amazed :)
Nice. :-)
I bet 4.7 would absolutely scream on a 4000-90 if it had CPU support.
The difference between 4.7 and 5.0 on a 2.8VUP MicroVAX-III is like
night and day...I can only imagine it on a 4000-90, more than ten times
faster!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 06/07/2012 06:55 AM, Mark Benson wrote:
Howabout starting it as a daemon (running as root) via the boot
scripts, and have non-root users's programs access it via a
socket?
Cool idea - you could even have multiple hosts connect this way but
export one DECNET endpoint, i.e. run CTERM on Box A whilst FAL goes
to Box B, and MAIL to Box C :)
Yes, you could multiplex/demultiplex it any way you wanted. It would
open up all sorts of interesting configuration possibilities.
... and all this without needing to dick with the kernel?
Sounds like a plan gentlemen, so now all we need is a long suffering
coder type to do all the hard work ;)
I'm already under the gun for a buttload of ARM7 code for work (which
is the only reason I'm still awake at this ungodly hour)...so not me, at
least not yet.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Al 07/06/12 13:06, En/na Dave McGuire ha escrit:
Oh, thanks. As I said, I've plenty of "modern" stuff, but I miss some of
the older software I used back in those days (pre-5.0), a (call it
nostalgia) I'm quite trying to reproduce that first environment I worked
on. Right now, I miss:
Will pre-5.0 VMS run on a 4000-90? I don't recall when NVAX CPU
support was added to VMS.
I don't think so. I've built a 4.7 system running in a 11-780 SIMH emulator :) I doubt 4.7 would run even in my 3300 (my oldest real machine).
BTW, 4.7 boots so fast under SIMH than at first I thought it had somehow crashed or hung. When I got the "username:" prompt after pressing return I was amazed :)
On 06/07/2012 06:49 AM, Sampsa Laine wrote:
Speaking of old software, does anybody happen to have WordPerfect for VMS lying around?
Would love to play with that..
I *think* I have it on a TK50 somewhere. It will be awhile before I
can dig through those tapes (I have hundreds of TK50s) but they're not
going anywhere just yet. I will set it aside if I find it, and make
sure to image it.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 06/07/2012 06:48 AM, Jordi Guillaumes i Pons wrote:
Jordi,
You wrote that the NIC on the 4000-90 was broken. Did you try an
external transceiver on the AUI connector (there's a switch on the back).
An Alllied Telesys or DEC transceiver might solve the issue. The logic
that drives the BNC connector is on a separate module IIRC.
I didn't. Actually, I thought you needed a thickwire segment to use a
transceiver and a drop cable. I should have researched it better. Any
idea of the DEC name for that thinwire transceiver?
(please forgive me for jumping in)
Welcome!
DEC sold 10base2 transceivers called "DESTA" (for Digital Ethernet
STation Adapter, I think) but it's so large that you'll need an AUI
cable to connect it. Others, from many different manufacturers, are
small enough to plug right onto the AUI connector. These are far more
common.
In my museum collection I have an internal DEC prototype of the DESTA.
Perhaps more conveniently, there are also of course a great many
10baseT transceivers out there that will plug directly onto an AUI
connector, small enough to not require an AUI cable.
Oh, thanks. As I said, I've plenty of "modern" stuff, but I miss some of
the older software I used back in those days (pre-5.0), a (call it
nostalgia) I'm quite trying to reproduce that first environment I worked
on. Right now, I miss:
Will pre-5.0 VMS run on a 4000-90? I don't recall when NVAX CPU
support was added to VMS.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 7 Jun 2012, at 11:42, Dave McGuire <mcguire at neurotica.com> wrote:
On 06/07/2012 06:37 AM, Sampsa Laine wrote:
Howabout starting it as a daemon (running as root) via the boot
scripts, and have non-root users's programs access it via a
socket?
Cool idea - you could even have multiple hosts connect this way but
export one DECNET endpoint, i.e. run CTERM on Box A whilst FAL goes
to Box B, and MAIL to Box C :)
Yes, you could multiplex/demultiplex it any way you wanted. It would
open up all sorts of interesting configuration possibilities.
... and all this without needing to dick with the kernel?
Sounds like a plan gentlemen, so now all we need is a long suffering
coder type to do all the hard work ;)
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
Speaking of old software, does anybody happen to have WordPerfect for VMS lying around?
Would love to play with that..
Sampsa
On 7 Jun 2012, at 11:48, Jordi Guillaumes i Pons wrote:
Al 07/06/12 12:11, En/na hvlems at zonnet.nl ha escrit:
Jordi,
You wrote that the NIC on the 4000-90 was broken. Did you try an external transceiver on the AUI connector (there's a switch on the back).
An Alllied Telesys or DEC transceiver might solve the issue. The logic that drives the BNC connector is on a separate module IIRC.
I didn't. Actually, I thought you needed a thickwire segment to use a transceiver and a drop cable. I should have researched it better. Any idea of the DEC name for that thinwire transceiver? (Or a compabtible one). Anyways, I think I canibalized that machine a little bit, so I'm not sure what is actually inside of the inclosure. It looks like a nice summer vacation project :)
If you need software kits for the VAX, post your needs. If I have the kit(s) I'll burn them on a CD. Hans
Oh, thanks. As I said, I've plenty of "modern" stuff, but I miss some of the older software I used back in those days (pre-5.0), a (call it nostalgia) I'm quite trying to reproduce that first environment I worked on. Right now, I miss:
- FMS
- TDMS
- VAX BASIC
- LSE
That's pretty all. I also used AI1 (the dreaded office package) but I'm not sure I'll want to fight that monster again ;). No need to burn a CD, we could arrange the transfer by network (HECnet or regular internet). I understand the use of that stuff is covered by the hobbyist license (not sure about TDMS though), so we would not do anything out of the law.
Al 07/06/12 12:11, En/na hvlems at zonnet.nl ha escrit:
Jordi,
You wrote that the NIC on the 4000-90 was broken. Did you try an external transceiver on the AUI connector (there's a switch on the back).
An Alllied Telesys or DEC transceiver might solve the issue. The logic that drives the BNC connector is on a separate module IIRC.
I didn't. Actually, I thought you needed a thickwire segment to use a transceiver and a drop cable. I should have researched it better. Any idea of the DEC name for that thinwire transceiver? (Or a compabtible one). Anyways, I think I canibalized that machine a little bit, so I'm not sure what is actually inside of the inclosure. It looks like a nice summer vacation project :)
If you need software kits for the VAX, post your needs. If I have the kit(s) I'll burn them on a CD. Hans
Oh, thanks. As I said, I've plenty of "modern" stuff, but I miss some of the older software I used back in those days (pre-5.0), a (call it nostalgia) I'm quite trying to reproduce that first environment I worked on. Right now, I miss:
- FMS
- TDMS
- VAX BASIC
- LSE
That's pretty all. I also used AI1 (the dreaded office package) but I'm not sure I'll want to fight that monster again ;). No need to burn a CD, we could arrange the transfer by network (HECnet or regular internet). I understand the use of that stuff is covered by the hobbyist license (not sure about TDMS though), so we would not do anything out of the law.
On 06/07/2012 06:37 AM, Sampsa Laine wrote:
Howabout starting it as a daemon (running as root) via the boot
scripts, and have non-root users's programs access it via a
socket?
Cool idea - you could even have multiple hosts connect this way but
export one DECNET endpoint, i.e. run CTERM on Box A whilst FAL goes
to Box B, and MAIL to Box C :)
Yes, you could multiplex/demultiplex it any way you wanted. It would
open up all sorts of interesting configuration possibilities.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
