On Aug 10, 2010, at 5:23 PM, Johnny Billquist wrote:
Zane H. Healy wrote:
On Tue, 10 Aug 2010, Brian Hechinger wrote:
On Tue, Aug 10, 2010 at 06:50:32AM -0400, Paul Koning wrote:
Yes, it should run most software just fine.
Excellent.
I'd personally be the most interested in RT-11 and RSTS/E. From the sound
of things, RT-11 at least should work.
RT-11 will probably be the best use of this in it's current form.
I think RSTS/E can run reasonably well without an FPP, but I'm sure Paul will correct me if I'm wrong.
RSTS doesn't much care if an FPP is present or not. Basic uses it if available, which makes float calculations significantly faster.
Lots of layered products require the FPP though.
I remember being told that Fortran-4-Plus requires FPP, while everything else either doesn't care or can be configured either way.
Then again, I must admit I don't know all that much about this. I've only rarely used FP myself...
paul
Zane H. Healy wrote:
On Tue, 10 Aug 2010, Brian Hechinger wrote:
On Tue, Aug 10, 2010 at 06:50:32AM -0400, Paul Koning wrote:
Yes, it should run most software just fine.
Excellent.
I'd personally be the most interested in RT-11 and RSTS/E. From the sound
of things, RT-11 at least should work.
RT-11 will probably be the best use of this in it's current form.
I think RSTS/E can run reasonably well without an FPP, but I'm sure Paul will correct me if I'm wrong.
Lots of layered products require the FPP though.
Non-MSCP disks can be done in logic; MSCP has always been implemented as firmware running on the storage controller. Presumably you'd want to do likewise here. That's certainly possible, with the help of an embedded processor inside the FPGA. Then you'd have to implement the MSCP firmware, which is a fair chunk of code. (I don't suppose anyone has the UDA50 firmware available? Then all you'd need is an FPGA model of the hardware, which would be easy by comparison.)
I *think* I've got a UDA50 laying around (or know someone who does), what would
be required to extract the firmware from it?
Even on the PDP-11, an RK05 is a bit tight. In fact it means that running
any semi-current OS would be challenging. I don't believe I have a UDA50,
but I'm pretty sure there is a KDA50 in my MicroVAX III (yes, I know that is
Q-Bus rather than Unibus).
One, or even four RK05 is definitely a challenge to run anything on. :-)
RT-11 is once more probably the best choice.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Aug 10, 2010, at 5:14 PM, Johnny Billquist wrote:
...
I don't think the UDA50 use any common microprocessor even, but is implemented with bitslices, and logic.
Correct. The main ingredients are AMD 2901 bitslice ALUs plus a 2910 sequencer.
Apparently the designer had a bunch of flexibility how those pieces go together. The UDA used a particularly interesting approach, where the micro-instruction would instruct the ALU part (2901) separate from the sequencer part (2910). The assembly language had two fields per line, one for each part.
There was a one clock delay between ALU result and branch control input. So you could read odd statements like this (paraphrasing... I don't remember the exact syntax):
clr r0 ; bne foo
because the bne would act on the ALU output from the preceding line.
I doubt that the processor part of the UDA50 would be all that hard to implement in an FPGA, but as you said, that isn't all that helpful if what you're after is MSCP support in the W11 FPGA.
paul
Paul Koning wrote:
On Aug 9, 2010, at 10:05 PM, Johnny Billquist wrote:
Brian Hechinger wrote:
If so I'm SOOOO buying a bunch of FPGAs to run that on. :-D
Yes, it should run most software just fine.
I have just a few gripes with this implementation. If they matter to you
or not is for you to decide:
1) No FPP. I think this is important, others might disagree.
2) Small disks. Only RK05 for now, and no plans for MSCP at all. While
future massbus is cool, by todays standards, fixed size, rather small
disks, are not that useful.
Non-MSCP disks can be done in logic; MSCP has always been implemented as firmware running on the storage controller. Presumably you'd want to do likewise here. That's certainly possible, with the help of an embedded processor inside the FPGA. Then you'd have to implement the MSCP firmware, which is a fair chunk of code. (I don't suppose anyone has the UDA50 firmware available? Then all you'd need is an FPGA model of the hardware, which would be easy by comparison.)
I think you'll go with something akin with firmware for whatever storage you choose, since it will not map easily with any backend you choose anyway.
That said, MSCP is still more complex than anything else, I agree. But it's also more useful.
Doing the whole UDA50 hardware in an FPGA would not be useful, since then you'd have something that would talk SDI. You'll not find anything today that talks SDI.
More meaningful in that case to do the CDU720, which uses SCSI as the backend. But I still think just implementing the basic needed for MSCP straight away is easier. We have enough of MSCP already figured out, and implemented for this to not be that hard today. The sources for simh is around, which implements enough of MSCP needed. Use that as the base.
And then map it to whatever backend you want to use.
3) Backend very dependant on some host machine with OS. I guess it helps
to make it doable faster, but for me, the really nice thing would be
something like USB interface to mass storage, which looks like MSCP from
the PDP-11 side. That would be *really* cool.
By far the easiest storage interface is IDE (ATA); is that still around? Well, it is, in CompactFlash cards... which would do nicely actually.
CF would be equally cool.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Brian Hechinger wrote:
On Tue, Aug 10, 2010 at 06:50:32AM -0400, Paul Koning wrote:
http://opencores.org/project,w11
Think that can run RSX/RSTS?
I'll have to take a look... a second reason to get an FPGA eval board...
It only runs on two boards, but at $100 for one, it's not a bad price, really.
Definitely an attractive price, yes.
I have just a few gripes with this implementation. If they matter to you
or not is for you to decide:
1) No FPP. I think this is important, others might disagree.
I get the feeling that's something he'll be adding. Does the lack of FPP affect
me currently? Probably not, but of course it would be nice to have.
Both from reading his information that he has published, and from my discussions with him, I get the impression that this is not high on his list, and might never be. But I might be wrong, which would be nice.
For me, this is definitely something that for means that I'm not interested. But as I said, others may very well have other views. I'm just giving my view on it.
2) Small disks. Only RK05 for now, and no plans for MSCP at all. While
future massbus is cool, by todays standards, fixed size, rather small
disks, are not that useful.
Yes, this I can agree with, most definitely.
Non-MSCP disks can be done in logic; MSCP has always been implemented as firmware running on the storage controller. Presumably you'd want to do likewise here. That's certainly possible, with the help of an embedded processor inside the FPGA. Then you'd have to implement the MSCP firmware, which is a fair chunk of code. (I don't suppose anyone has the UDA50 firmware available? Then all you'd need is an FPGA model of the hardware, which would be easy by comparison.)
I *think* I've got a UDA50 laying around (or know someone who does), what would
be required to extract the firmware from it?
I really don't see the point. The firmware is located in a bunch of proms. Might be 2732 or something similar, if I remember right. But extracting the data from these will not be much help. You need to remember that the UDA50 is a "computer", so this will be the firmware for that machine. And it's a specific machine for just doing the UDA50. So, in order to have this firmware useful, you would need to implement the same "computer" as the UDA50 is.
Or else decode the machine code of that hardware, so that you then can disassemble the firmware. But what good would that be? The MSCP protocol as such is already known (with a few exceptions), so all this will give in addition is how the UDA50 Unibus interface is implemented, and how the SDI interface works. Neither of which is that useful information either.
I don't think the UDA50 use any common microprocessor even, but is implemented with bitslices, and logic.
3) Backend very dependant on some host machine with OS. I guess it helps
to make it doable faster, but for me, the really nice thing would be
something like USB interface to mass storage, which looks like MSCP from
the PDP-11 side. That would be *really* cool.
By far the easiest storage interface is IDE (ATA); is that still around? Well, it is, in CompactFlash cards... which would do nicely actually.
Yes, I agree, the backend server bothers me a bit as well. I've love to have
something I could plug a CF card and an ethernet cable into and be done with
it.
I would not mind a IDE, ATA, or any other kindof common modern interface with small, solid state mass storage. The backend is, in this case, not for me important. Just having one that is common, for which storage is cheap and small would be enough. But unless you go MSCP for the PDP11 side, you'll be talking disks with sizes that are just a fraction of any storage existing today. The absolutely largest non-MSCP storage is the RP07, which is Massbus, and that's still only about 0.5G.
That all being said, I'm sure this guy isn't done and who knows, send him your
suggestions, he might be up for it. :-D
Oh, he definitely don't mind suggestions and opinions. Go ahead and talk with him.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Aug 10, 2010, at 1:09 PM, Brian Hechinger wrote:
On Tue, Aug 10, 2010 at 06:50:32AM -0400, Paul Koning wrote:
http://opencores.org/project,w11
Think that can run RSX/RSTS?
I'll have to take a look... a second reason to get an FPGA eval board...
It only runs on two boards, but at $100 for one, it's not a bad price, really.
I have some other reasons for getting a much higher end (and unfortunately more expensive) board... any changes needed for that should be easy enough.
The larger FPGAs will be able to have main memory on-chip. That makes the cache unnecessary, though the effort to take it out might not be worth the trouble.
...
Non-MSCP disks can be done in logic; MSCP has always been implemented as firmware running on the storage controller. Presumably you'd want to do likewise here. That's certainly possible, with the help of an embedded processor inside the FPGA. Then you'd have to implement the MSCP firmware, which is a fair chunk of code. (I don't suppose anyone has the UDA50 firmware available? Then all you'd need is an FPGA model of the hardware, which would be easy by comparison.)
I *think* I've got a UDA50 laying around (or know someone who does), what would
be required to extract the firmware from it?
Actually, on reconsideration I spoke too fast. While that would give you a reference for the host end (PDP-11 end) of MSCP, it would also give you lots of extraneous stuff that would only make things harder: Unibus interface machinery, interfacing to the disks and the SI links, etc.
The simpler answer is probably to pick up a disk emulation from one of the emulators, and run that in an embedded CPU inside the FPGA. Various embedded small processors are readily available; some even come with GCC support.
3) Backend very dependant on some host machine with OS. I guess it helps
to make it doable faster, but for me, the really nice thing would be
something like USB interface to mass storage, which looks like MSCP from
the PDP-11 side. That would be *really* cool.
By far the easiest storage interface is IDE (ATA); is that still around? Well, it is, in CompactFlash cards... which would do nicely actually.
Yes, I agree, the backend server bothers me a bit as well. I've love to have
something I could plug a CF card and an ethernet cable into and be done with
it.
CF card interface is just like an old ATA disk; it's quite easy. Ethernet is a bit harder. Ethernet cores are available for many FPGAs, either hard dedicated logic (like in the Xilinx Virtex series) or as soft cores. Come to think of it, some are available on opencores.org. Eval boards may well come with this, including the necessary VHDL.
And I'll echo what Bob Armstrong said: consider this an opportunity to do some neat hacking. VHDL is not that hard to learn. http://www.ashenden.com.au/vhdl-book/DG3E.html is a very good textbook. (I can't find it on Amazon for some reason, though I'm pretty sure that's where I got it originally...)
paul
I'm not going to quote anybody's posting here, but there have been several
that motivated me to speak up. I have say that this is really pathetic. A
guy (Walter Mueller, the original author it looks like) does all the work to
implement a 11/70 in VHDL, gives it away to you _for free_, and all you guys
do is sit around and make lists of the stuff he didn't do. If you want an
FPU, write the VHDL for one. If you want an MSCP disk, then implement one.
Contribute. Help. Take some of that energy you use to write these emails
and use it to make the core better. That's what Open Source is all about,
guys.
</soapbox> Sorry. I see this attitude the time with Spare Time Gizmos
and I've become kind of sensitive to and intolerant of it. I'll go back to
sleep now.
Bob
On Tue, 10 Aug 2010, Brian Hechinger wrote:
On Tue, Aug 10, 2010 at 06:50:32AM -0400, Paul Koning wrote:
http://opencores.org/project,w11
Think that can run RSX/RSTS?
I'll have to take a look... a second reason to get an FPGA eval board...
It only runs on two boards, but at $100 for one, it's not a bad price, really.
Hmmm, that isn't a bad price.
Yes, it should run most software just fine.
Excellent.
I'd personally be the most interested in RT-11 and RSTS/E. From the sound
of things, RT-11 at least should work.
2) Small disks. Only RK05 for now, and no plans for MSCP at all. While
future massbus is cool, by todays standards, fixed size, rather small
disks, are not that useful.
Yes, this I can agree with, most definitely.
Non-MSCP disks can be done in logic; MSCP has always been implemented as firmware running on the storage controller. Presumably you'd want to do likewise here. That's certainly possible, with the help of an embedded processor inside the FPGA. Then you'd have to implement the MSCP firmware, which is a fair chunk of code. (I don't suppose anyone has the UDA50 firmware available? Then all you'd need is an FPGA model of the hardware, which would be easy by comparison.)
I *think* I've got a UDA50 laying around (or know someone who does), what would
be required to extract the firmware from it?
Even on the PDP-11, an RK05 is a bit tight. In fact it means that running
any semi-current OS would be challenging. I don't believe I have a UDA50,
but I'm pretty sure there is a KDA50 in my MicroVAX III (yes, I know that is
Q-Bus rather than Unibus).
Yes, I agree, the backend server bothers me a bit as well. I've love to have
something I could plug a CF card and an ethernet cable into and be done with
it.
Considering that I can plug SD cards, and an ethernet cable into my
Commodore 64, I couldn't agree more.
Zane
On Tue, Aug 10, 2010 at 06:50:32AM -0400, Paul Koning wrote:
http://opencores.org/project,w11
Think that can run RSX/RSTS?
I'll have to take a look... a second reason to get an FPGA eval board...
It only runs on two boards, but at $100 for one, it's not a bad price, really.
Yes, it should run most software just fine.
Excellent.
I have just a few gripes with this implementation. If they matter to you
or not is for you to decide:
1) No FPP. I think this is important, others might disagree.
I get the feeling that's something he'll be adding. Does the lack of FPP affect
me currently? Probably not, but of course it would be nice to have.
2) Small disks. Only RK05 for now, and no plans for MSCP at all. While
future massbus is cool, by todays standards, fixed size, rather small
disks, are not that useful.
Yes, this I can agree with, most definitely.
Non-MSCP disks can be done in logic; MSCP has always been implemented as firmware running on the storage controller. Presumably you'd want to do likewise here. That's certainly possible, with the help of an embedded processor inside the FPGA. Then you'd have to implement the MSCP firmware, which is a fair chunk of code. (I don't suppose anyone has the UDA50 firmware available? Then all you'd need is an FPGA model of the hardware, which would be easy by comparison.)
I *think* I've got a UDA50 laying around (or know someone who does), what would
be required to extract the firmware from it?
3) Backend very dependant on some host machine with OS. I guess it helps
to make it doable faster, but for me, the really nice thing would be
something like USB interface to mass storage, which looks like MSCP from
the PDP-11 side. That would be *really* cool.
By far the easiest storage interface is IDE (ATA); is that still around? Well, it is, in CompactFlash cards... which would do nicely actually.
Yes, I agree, the backend server bothers me a bit as well. I've love to have
something I could plug a CF card and an ethernet cable into and be done with
it.
That all being said, I'm sure this guy isn't done and who knows, send him your
suggestions, he might be up for it. :-D
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
On Mon, 2010-08-09 at 17:25 +0100, Sampsa Laine wrote:
Dunno about VMS, but I use fetchmail on Unix to do just that - you can
then tell fetchmail to feed it to the VMS box over SMTP.
It's exactly how CHIMPYMAIL.COM works.
I got fetchmail setup ok - how do I forward to the VMS box?
Cheers for the help, Mark.
Dunno about VMS, but I use fetchmail on Unix to do just that - you can then tell fetchmail to feed it to the VMS box over SMTP.
It's exactly how CHIMPYMAIL.COM works.
Sampsa
On 9 Aug 2010, at 17:17, Mark Wickens wrote:
On Thu, 2010-08-05 at 23:10 +0200, Sampsa Laine wrote:
I use Google Apps for all my domains, which I then pull down using
fetchmail onto a Unix (in this case OS X server).
On Thu, 2010-08-05 at 23:10 +0200, Sampsa Laine wrote:
I use Google Apps for all my domains, which I then pull down using
fetchmail onto a Unix (in this case OS X server).
At 3:46 PM +0100 8/5/10, Mark Wickens wrote:
Collective Wisdom,
I'd like to bring email from my current remote hosted IMAP server
in-house. Can anyone provide guidance on solutions? I'd like access from
standard email clients but would also like to be able to ssh into a
local box and read mail via a character terminal.
I have an OpenVMS and Linux server available to serve.
Thanks, Mark.
I used OpenVMS for about 10 years at home for an email server. I started with a AlphaStation 200 4/233 and ended with an XP1000/667.
I did run into one problem where some worthless SOB spoofed my domain for spamming and I got a *LOT* of bounces. The resulting DOS attack took the box down for a couple days. I think it was an AlphaStation 600/433au at the time.
The only reason I'm not currently running the system is that it costs to much to run a XP1000/667 with 6 10k SCSI drives 24x7, and since buying a house, I've not sorted out cooling. I've been thinking about bringing an AlphaStation 200 4/233 back online for this and a couple other things that I need VMS for. It is driving me crazy not having my own VMS system running.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com | OpenVMS Enthusiast |
| | Photographer |
+----------------------------------+----------------------------+
| My flickr Photostream |
| http://www.flickr.com/photos/33848088 at N03/ |
On Thu, 2010-08-05 at 15:23 -0400, Joe Ferraro wrote:
As much as I can't stand Big Brother -- eh hem -- Google... if you're
not talking a hobbyist solution, its just downright difficult to beat
their imap / pop3 / web email solution -- especially when blasted SPAM
is considered.
If you have trouble with the fact that google aggressively analyzes,
stores and sells your data trends -- you might want to look at `exim`
for linux.
I've been reading some right horror stories about people who have had
their email accounts removed unconditionally due to suspected spamming
(through no fault of their own, and this is people who've paid for a
service) with no comeback and in some cases no way to get a response,
this has included websites, so I'd rather keep the solution in-house.
I'd get perverse pleasure from using allin1, but it's my understanding
that I would need a tru64 box running permanently to run the mailbus to
smtp gateway, and I'd rather not do that.
I'm happy to give a VMS solution a go - I use messagebunker, so should
be safe in the knowledge that everything is backed up.
Mark
If you want someone else to host your email and don't want it to be google, i'd
be more than happy to host anyone's email. I promise not to read your email and
stuff.
Really. :-D
-brian
On Thu, Aug 05, 2010 at 03:23:12PM -0400, Joe Ferraro wrote:
As much as I can't stand Big Brother -- eh hem -- Google... if you're not
talking a hobbyist solution, its just downright difficult to beat their imap
/ pop3 / web email solution -- especially when blasted SPAM is considered.
If you have trouble with the fact that google aggressively analyzes, stores
and sells your data trends -- you might want to look at `exim` for linux.
Joe
On Thu, Aug 5, 2010 at 1:06 PM, Fred <fcoffey at thrifty.misernet.net> wrote:
On Thu, 5 Aug 2010, Mark Wickens wrote:
standard email clients but would also like to be able to ssh into a
local box and read mail via a character terminal.
I do both. I run Linux/Postfix and OpenVMS/PMDF. I can SSH into my Linux
box and then check my mail with (al)pine (like I am doing now) and also
telnet into my Alpha and read the mail with MAIL or PINE that is included
with PMDF.
Fred
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
As much as I can't stand Big Brother -- eh hem -- Google... if you're not talking a hobbyist solution, its just downright difficult to beat their imap / pop3 / web email solution -- especially when blasted SPAM is considered.
If you have trouble with the fact that google aggressively analyzes, stores and sells your data trends -- you might want to look at `exim` for linux.
Joe
On Thu, Aug 5, 2010 at 1:06 PM, Fred <fcoffey at thrifty.misernet.net> wrote:
On Thu, 5 Aug 2010, Mark Wickens wrote:
standard email clients but would also like to be able to ssh into a
local box and read mail via a character terminal.
I do both. I run Linux/Postfix and OpenVMS/PMDF. I can SSH into my Linux box and then check my mail with (al)pine (like I am doing now) and also telnet into my Alpha and read the mail with MAIL or PINE that is included with PMDF.
Fred
On Thu, 5 Aug 2010, Mark Wickens wrote:
standard email clients but would also like to be able to ssh into a
local box and read mail via a character terminal.
I do both. I run Linux/Postfix and OpenVMS/PMDF. I can SSH into my Linux box and then check my mail with (al)pine (like I am doing now) and also telnet into my Alpha and read the mail with MAIL or PINE that is included with PMDF.
Fred
On 5.8.2010 18:44, Brian Hechinger wrote:
On Thu, Aug 05, 2010 at 11:36:13AM -0400, Steve Davidson wrote:
standard email clients but would also like to be able to ssh into a
local box and read mail via a character terminal.
I use a variety of OS platforms to provide email availability and I have found
that either NetBSD or Linux is the easiest to deal with and since you already
have Linux that would be the direction I would suggest.
As much as I'd love to run a mail server on VMS, I would have to agree with Steve
on this one.
As to accessing mail from a terminal vi ssh, I do exactly that myself. What I have
been doing is I run mutt locally on the mail server, but I've configured it to use
IMAP to access the mail server. It has worked very well.
-brian
Maybe I have to give the opposite opinion to keep the balance. :)
I have been running my own mail server on VMS and some other organizations servers as well. I'm not talking about my work where I've been doing it, too.
It is very simple to configure a mail server just with the native software (VMS and UCX or TCP/IP). You just run sys$manager:tcpip$config and then configure the SMTP server and the selection of client protocol you want to use (IMAP or POP3).
You can then use a browser-based mail client (e.g. Firefox), some other external client like Thunderbird or the regular VMS mail client (CLI).
There are more sophisticated mail server software for VMS like PMDF, All-In-One (aka Office Server), MX, etc.
Some of them are licensed for Hobbyists, but they need more effort to configure and maintain, but they also provide more features. It is your choice.
My point here is that it is really easy to use VMS as a mail server platform. There are natively some features which aren't found out-of-the-box on unices. One of them is DOS attack resistance and another is Intrusion Detection and avoidance.
If you like to know more, I'll be happy to help.
Kari
On 08/05/2010 11:36 PM, Steve Davidson wrote:
Mark Wickens
Collective Wisdom,
I'd like to bring email from my current remote hosted IMAP server
in-house. Can anyone provide guidance on solutions? I'd like access from
standard email clients but would also like to be able to ssh into a
local box and read mail via a character terminal.
I have an OpenVMS and Linux server available to serve.
Thanks, Mark.
Mark,
I would go with the Linux platform. As much as I prefer VMS over Linux let's
face it, you will find more support for the Linux platform in this space.
I would disagree on this point. If this is a hobbyist effort, then PMDF
from Process Software is certainly free and feature rich. It can be
found at:
www.process.com
Tim.
On Thu, Aug 05, 2010 at 11:36:13AM -0400, Steve Davidson wrote:
standard email clients but would also like to be able to ssh into a
local box and read mail via a character terminal.
I use a variety of OS platforms to provide email availability and I have found
that either NetBSD or Linux is the easiest to deal with and since you already
have Linux that would be the direction I would suggest.
As much as I'd love to run a mail server on VMS, I would have to agree with Steve
on this one.
As to accessing mail from a terminal vi ssh, I do exactly that myself. What I have
been doing is I run mutt locally on the mail server, but I've configured it to use
IMAP to access the mail server. It has worked very well.
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
Mark Wickens
Collective Wisdom,
I'd like to bring email from my current remote hosted IMAP server
in-house. Can anyone provide guidance on solutions? I'd like access from
standard email clients but would also like to be able to ssh into a
local box and read mail via a character terminal.
I have an OpenVMS and Linux server available to serve.
Thanks, Mark.
Mark,
I would go with the Linux platform. As much as I prefer VMS over Linux let's
face it, you will find more support for the Linux platform in this space.
I use a variety of OS platforms to provide email availability and I have found
that either NetBSD or Linux is the easiest to deal with and since you already
have Linux that would be the direction I would suggest.
-Steve
Collective Wisdom,
I'd like to bring email from my current remote hosted IMAP server
in-house. Can anyone provide guidance on solutions? I'd like access from
standard email clients but would also like to be able to ssh into a
local box and read mail via a character terminal.
I have an OpenVMS and Linux server available to serve.
Thanks, Mark.
On Thu, Jul 29, 2010 at 10:28:29PM +0200, Johnny Billquist wrote:
Yes, but I'm not talking about the TAP interface per se, but of the
bridging function. How does that work... Does it bridge any ethernet
frame, or does it only bridge ip packets...
Ethernet frames.
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
Brian Hechinger wrote:
On Thu, Jul 29, 2010 at 09:53:59PM +0200, Johnny Billquist wrote:
Do you have IP addresses set on both TAP interfaces? Does the Solaris
No, the one has an IP, the other (which is the one SIMH talks to) doesn't
as the IP "exists" in VMS, not at the host level.
bridging bridge everything or just ip? If it just bridge ip you might need to have IP addresses on both TAP interfaces for it to be happy. Check all the details you can find on how the bridge stuff works under Solaris.
TAP is the raw ethernet interface, it bridges raw ethernet frames, not IP,
so it *should* just do the right thing. (Like that guy does on linux with it)
That's the theory anyway. :-D
Yes, but I'm not talking about the TAP interface per se, but of the bridging function. How does that work... Does it bridge any ethernet frame, or does it only bridge ip packets...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
