3B2 Disks
awe...@gmail.com
I have a 3b2 that works but whose password has been lost to the ages.
I have a copy of the disk images for the 3b2 including the "System
Essentials" disk, but I need to find a way to get these onto a floppy.
The alternative, of course, is to find a way to read the passwd file
off of the 3b2's MFM harddrive.
Both of these I have attempted and haven't been successful with. Any
help would be appreciated.
--
Andrew Wesie
DoN. Nichols
> [Originally posted in comp.sys.att. Forwarded here on recommendation.]
>
> I have a 3b2 that works but whose password has been lost to the ages.
> I have a copy of the disk images for the 3b2 including the "System
> Essentials" disk, but I need to find a way to get these onto a floppy.
O.K. I've never worked with a 3B2 -- just the 3B1 -- but what
is the floppy size -- 5.25" or 3.5"
If the former, based on how the 3B1 did it, some disks were 8
sectors/track and others were 10 sectors/track. (You can tell based on
how large the whole file is. The boot floppys had to be 8
sectors/track, but once a later OS was in, the rest could be 10 S/T.
8 S/T is a bit easier to manage with a PC, as the standard was 9
S/T, so you could simply not use one per track.
10 S/T was possible with a version of linux on a PC, compiled
with support for the 3B1 floppy format.
> The alternative, of course, is to find a way to read the passwd file
> off of the 3b2's MFM harddrive.
Best there would likely be a 3B1 or another 3B2 with capability
to read the disk format. The 3B1 was designed for one MFM drive, but
could be modified to handle a second one.
If the system used a SCSI drive (IIRC, there were some with MFM
to SCSI adaptors), you could hang it on another unix box and just access
it in raw mode sector-by-sector until you found the password file.
Or -- could it be that someone left the "guest" account password
free? If so, you can list the password file (it is world readable,
because it needs to be accessed by lots of programs for information
about file ownership and the like), so you should be able to see the
encrypted (really hashed) passwords. You can then copy the one you need
to another system and start attacking it -- with a program like security
program like "crack" or "jack the ripper" (which look for weak passwords
by attacking them, and cracking them if possible), *or* you could
replace the password on the disk by raw disk edits with the hash of a
known one. (They are all the same length until recent systems which
allow other hashing systems.) Just edit in the proper characters one at
a time, then boot from the disk and log in.
I have done both of these with older systems. I used the 3B1 to
attempt possible passwords from /usr/dict/words with a single salt
(extracted from the unknown password) on a Tektronix 6130, and the raw
disk attack on a disk from an Intergraph Interact 32/C (IIRC). That
latter one was a real pain. I got in, but it only had demo copies of
licensed things like the networking and the compilers installed, which
timed out before I was through playing with it. :-(
There may be security holes in the 3B2 like the ones in the 3B1
(the "mail" icon was one of them), but you will need someone more
familiar with the 3B2. (I *keep* tying 3B1 when I mean 3B2 -- shows what
habit my fingers have learned over the years, and not forgotten.
> Both of these I have attempted and haven't been successful with. Any
> help would be appreciated.
You have my suggestions. What will work depends on what the
hardware is, and how much other hardware you have on hand.
Enjoy,
DoN.
--
Email: <dnic...@d-and-d.com> | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---
Bill Gunshannon
"DoN. Nichols" <dnic...@d-and-d.com> writes:
> On 2009-01-11, awe...@gmail.com <awe...@gmail.com> wrote:
>> [Originally posted in comp.sys.att. Forwarded here on recommendation.]
>>
>> I have a 3b2 that works but whose password has been lost to the ages.
>> I have a copy of the disk images for the 3b2 including the "System
>> Essentials" disk, but I need to find a way to get these onto a floppy.
>
> O.K. I've never worked with a 3B2 -- just the 3B1 -- but what
> is the floppy size -- 5.25" or 3.5"
>
The 3B1 and the 3B2 have nothing in common with each other. The 3B1 was
a Convergent Technologies box sold by AT&T and the 3B2 was an AT&T designed
and manufactured box using the WE32000 CPU. I will look later today, but,
sadly, I believe I threw all my 3B2 software away years ago when my last
3B2 died. If I still have any of them, they yours for the postage.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
DoN. Nichols
> In article <slrngmirtg....@katana.d-and-d.com>,
> "DoN. Nichols" <dnic...@d-and-d.com> writes:
>> On 2009-01-11, awe...@gmail.com <awe...@gmail.com> wrote:
>>> [Originally posted in comp.sys.att. Forwarded here on recommendation.]
>>>
>>> I have a 3b2 that works but whose password has been lost to the ages.
>>> I have a copy of the disk images for the 3b2 including the "System
>>> Essentials" disk, but I need to find a way to get these onto a floppy.
>>
>> O.K. I've never worked with a 3B2 -- just the 3B1 -- but what
>> is the floppy size -- 5.25" or 3.5"
>>
>
> The 3B1 and the 3B2 have nothing in common with each other.
The vendor. And the fact that they both are computers.
And the fact that they both ran SysVr? OS versions (with various
add-ons. :-)
And -- I've got a 3B2 external drive housing attached to one of
my 3B1s, to hold both the boot drive (no longer internal) and the second
drive, plus a "floppy tape" drive. Granted, it took a bit of creative
wiring to do that all.
But since they both were SysV unix, there may well be enough
similarity in disk formats to allow one to look at a disk belonging to
the other.
And *any* SCSI disk (if his system uses SCSI, either a direct
SCSI disk, or a MFM or such adapted to SCSI by an external card) should
be readable on a sector-by-sector basis to allow some of my suggestions
to work. After all -- the two systems which I described gaining access
to were not even AT&T products -- one was Tektronix with the NS 32016
CPU, and the other was Intergraph with a Fairchild "clipper" CPU. The
first ran a BSD flavor of OS, and the second a SysV flavor. The first I
broke the password on using a 3B1 as the password cracking engine, and
the second I accessed the raw sectors on using a Sun 2/140 (BSD to
access a drive from a SysV based system.
> The 3B1 was
> a Convergent Technologies box sold by AT&T and the 3B2 was an AT&T designed
> and manufactured box using the WE32000 CPU.
Both with the AT&T "Death Star" logo, and similar color schemes,
FWIMBW.
> I will look later today, but,
> sadly, I believe I threw all my 3B2 software away years ago when my last
> 3B2 died. If I still have any of them, they yours for the postage.
And -- if you *don't* have them, it is still possible that he
may be able to use some of the ideas which I covered.
Bill Gunshannon
"DoN. Nichols" <dnic...@d-and-d.com> writes:
> On 2009-01-11, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>> In article <slrngmirtg....@katana.d-and-d.com>,
>> "DoN. Nichols" <dnic...@d-and-d.com> writes:
>>> On 2009-01-11, awe...@gmail.com <awe...@gmail.com> wrote:
>>>> [Originally posted in comp.sys.att. Forwarded here on recommendation.]
>>>>
>>>> I have a 3b2 that works but whose password has been lost to the ages.
>>>> I have a copy of the disk images for the 3b2 including the "System
>>>> Essentials" disk, but I need to find a way to get these onto a floppy.
>>>
>>> O.K. I've never worked with a 3B2 -- just the 3B1 -- but what
>>> is the floppy size -- 5.25" or 3.5"
>>>
>>
>> The 3B1 and the 3B2 have nothing in common with each other.
>
> The vendor. And the fact that they both are computers.
>
> And the fact that they both ran SysVr? OS versions (with various
> add-ons. :-)
>
> And -- I've got a 3B2 external drive housing attached to one of
> my 3B1s, to hold both the boot drive (no longer internal) and the second
> drive, plus a "floppy tape" drive. Granted, it took a bit of creative
> wiring to do that all.
>
> But since they both were SysV unix, there may well be enough
> similarity in disk formats to allow one to look at a disk belonging to
> the other.
>
I gave some thought to recommending hooking one of the disks up
to another computer, but regardless of the possibility of the
filesystems being compatable I doubt the controllers used would
allow for something other than another member of the 3B2 family
(3B12/3B15/3B20) being able to read the disk in its present format.
But I suppose there would be no loss in trying.
> And *any* SCSI disk (if his system uses SCSI, either a direct
> SCSI disk, or a MFM or such adapted to SCSI by an external card) should
> be readable on a sector-by-sector basis to allow some of my suggestions
> to work. After all -- the two systems which I described gaining access
> to were not even AT&T products -- one was Tektronix with the NS 32016
> CPU, and the other was Intergraph with a Fairchild "clipper" CPU. The
> first ran a BSD flavor of OS, and the second a SysV flavor. The first I
> broke the password on using a 3B1 as the password cracking engine, and
> the second I accessed the raw sectors on using a Sun 2/140 (BSD to
> access a drive from a SysV based system.
I guess anything is worth the try if the alternative is to use them
as doorstops (something they do quite well, actually). Funny you
should mention SCSI. I actually heard there was a 3Bfamily SCSI
controller but I suspect they were even rarer than QBUS or UNIBUS
SCSI controllers. Well, maybe they became popular after NCR took
over the running of AT&T's 3Bfamily. Did you ever hear about the
NCR "upgrade" for the 3B2 computer systems? :-)
>
>> The 3B1 was
>> a Convergent Technologies box sold by AT&T and the 3B2 was an AT&T designed
>> and manufactured box using the WE32000 CPU.
>
> Both with the AT&T "Death Star" logo, and similar color schemes,
> FWIMBW.
Yeah, also sported by the AT&T 6300 family which was made by Olivetti
in Italy. And wasn't compatable with anything, not even the IBM PC
which was the actual model for the hardware.
>
>> I will look later today, but,
>> sadly, I believe I threw all my 3B2 software away years ago when my last
>> 3B2 died. If I still have any of them, they yours for the postage.
>
> And -- if you *don't* have them, it is still possible that he
> may be able to use some of the ideas which I covered.
He is free to do whatever he wants. It's just that having had a number
of them myself I was offering my experience which was that they were
not really compatable with anything (that, I am fairly certain, was by
design) and by todays standards not really worth a lot of effort. While
I really liked the processor (and I have the architecture manual here
somewhere, I know I kept that for my library) many of the components were
did not seem particularly well made and eventually all of mine failed.
Compare that to how many other, much older computers are still in
almost daily use.
I wish him luck. Oh yeah, I looked. Either I gave away or threw away
all the sets of software I had. I suspect gave away as I seldom throw
any software out and would more likely have recycled the floppy disks.
I do still have the floppy drives, the floppy tapes and I think I may
even still have the hard disks here somewhere. I have always wanted to
see if I could write a driver to let me use the tape drives on something
like a PDP-11.
DoN. Nichols
> In article <slrngml5q6....@katana.d-and-d.com>,
> "DoN. Nichols" <dnic...@d-and-d.com> writes:
>> On 2009-01-11, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
[ ... ]
>>> The 3B1 and the 3B2 have nothing in common with each other.
>>
>> The vendor. And the fact that they both are computers.
>>
>> And the fact that they both ran SysVr? OS versions (with various
>> add-ons. :-)
>>
>> And -- I've got a 3B2 external drive housing attached to one of
>> my 3B1s, to hold both the boot drive (no longer internal) and the second
>> drive, plus a "floppy tape" drive. Granted, it took a bit of creative
>> wiring to do that all.
[ ... ]
> I gave some thought to recommending hooking one of the disks up
> to another computer, but regardless of the possibility of the
> filesystems being compatable I doubt the controllers used would
> allow for something other than another member of the 3B2 family
> (3B12/3B15/3B20) being able to read the disk in its present format.
> But I suppose there would be no loss in trying.
If it is purely a MFM drive, yes, it would be difficult to
access from another system.
But a friend had a 3B2 which had a SCSI interface, and used MFM
(or were they IDSE) drives on a shared adaptor. I believe that the
adaptor could handle up to four drives at once, but he only had two on
it.
Those drives, *with* the adaptor, could be accessed a sector at
a time from any SCSI system using the "raw" interface. It would be
fairly easy to write a C program which would do that and look for a
sector which started "root:.*:0:0:" (Wildcarding for the password field
to allow for no password (not the case here), a real password, or a
redirection to a shadow password, depending on the age of the system.
If a redirection, then re-do the program to look for "root:.*:" without
the "0:0:".
Given the age of the system, the length of the password field
would be constant with the standard password hashing system, making it
easy to do a raw disk edit on that one sector to replace it with the
hash of a *known* password. (Anything which changed the length of the
field would of course require adjusting everything which followed in the
password file.
>> And *any* SCSI disk (if his system uses SCSI, either a direct
>> SCSI disk, or a MFM or such adapted to SCSI by an external card) should
>> be readable on a sector-by-sector basis to allow some of my suggestions
>> to work. After all -- the two systems which I described gaining access
>> to were not even AT&T products -- one was Tektronix with the NS 32016
>> CPU, and the other was Intergraph with a Fairchild "clipper" CPU. The
>> first ran a BSD flavor of OS, and the second a SysV flavor. The first I
>> broke the password on using a 3B1 as the password cracking engine, and
>> the second I accessed the raw sectors on using a Sun 2/140 (BSD to
>> access a drive from a SysV based system.
>
> I guess anything is worth the try if the alternative is to use them
> as doorstops (something they do quite well, actually).
You want a serious doorstop? Try my Ingergraph Interact 32/C.
Two 19" monitors mounted on top of a wheeled chassis containing most of
the rest, with a big (24x36" IIRC) digitizing tablet hinged to the front
with an air cylinder to allow adjusting the angle while a pressure point
was pinched. The digitizing tablet and the puck acted as the mouse,
with about a dozen buttons on it.
It was designed as a graphics workstation, but I didn't have the
software to use it as such. I now have the software, but I don't have
the license keys to allow me to use the software.
The edge of the digitizing tablet had another pair of pressure
points to raise or lower the tablet and the monitors as a unit, and
another pair to tilt the monitors forward or back to adjust so you
could use it comfortably seated low, on a draftsman's stool, or
standing.
> Funny you
> should mention SCSI. I actually heard there was a 3Bfamily SCSI
> controller but I suspect they were even rarer than QBUS or UNIBUS
> SCSI controllers. Well, maybe they became popular after NCR took
> over the running of AT&T's 3Bfamily.
Hmm ... I'm afraid that I can't ask the friend about it, as he
is no longer with us.
> Did you ever hear about the
> NCR "upgrade" for the 3B2 computer systems? :-)
No -- how bad was it?
>>> The 3B1 was
>>> a Convergent Technologies box sold by AT&T and the 3B2 was an AT&T designed
>>> and manufactured box using the WE32000 CPU.
>>
>> Both with the AT&T "Death Star" logo, and similar color schemes,
>> FWIMBW.
>
> Yeah, also sported by the AT&T 6300 family which was made by Olivetti
> in Italy. And wasn't compatable with anything, not even the IBM PC
> which was the actual model for the hardware.
And -- it had to have the date routine in the OS patched every
eight years. The clock chip in that only counted through eight years
(just enough so it would keep the right years as leap years), and the
patch added the proper starting point to the eight-year count in the
chip.
A friend was still working at a place which used these things
when the *second* update time came around, and I was able to get the
patch for her through the help of someone in this very newsgroup. But
imagine a *business* still using a 16-year old PC sorta clone. :-)
>>> I will look later today, but,
>>> sadly, I believe I threw all my 3B2 software away years ago when my last
>>> 3B2 died. If I still have any of them, they yours for the postage.
>>
>> And -- if you *don't* have them, it is still possible that he
>> may be able to use some of the ideas which I covered.
>
> He is free to do whatever he wants. It's just that having had a number
> of them myself I was offering my experience which was that they were
> not really compatable with anything (that, I am fairly certain, was by
> design) and by todays standards not really worth a lot of effort.
Well ... I just recently acquired a SGI Indigo 2 (the version
with the really weird R8000 MIPS processor which had floating point as
fast as integer math.
One reason for wanting to bring it back to life is that they had
the only DAT drives which were capable of reading and writing *audio*
DATs as well as backup tapes -- complete with a graphical sound editing
program back in 1995. :-)
> While
> I really liked the processor (and I have the architecture manual here
> somewhere, I know I kept that for my library) many of the components were
> did not seem particularly well made and eventually all of mine failed.
> Compare that to how many other, much older computers are still in
> almost daily use.
But -- the 3B2 was the porting base for unix for some time. (I
guess that the higher numbered 3B* systems were a fairly easy port from
the 3B2 software.
And I've still got (but have retired) my first unix box, a
COSMOS CMS16/UNX (Motorola 8 MHz 68000 CPU with v7 unix in an Intel
Multibus chassis.) *And* -- I still have the manuals and the 11 8" DSDD
floppies which made the OS distribution.
> I wish him luck. Oh yeah, I looked. Either I gave away or threw away
> all the sets of software I had. I suspect gave away as I seldom throw
> any software out and would more likely have recycled the floppy disks.
> I do still have the floppy drives, the floppy tapes and I think I may
> even still have the hard disks here somewhere. I have always wanted to
> see if I could write a driver to let me use the tape drives on something
> like a PDP-11.
Did you ever hear of the PDP-11 which ran unix from a DECTAPE?
Swapping and everything on that one tape drive. :-)
awe...@gmail.com
>
> O.K. I've never worked with a 3B2 -- just the 3B1 -- but what
> is the floppy size -- 5.25" or 3.5"
>
images are 720kb.
>
> Best there would likely be a 3B1 or another 3B2 with capability
> to read the disk format. The 3B1 was designed for one MFM drive, but
> could be modified to handle a second one.
>
> If the system used a SCSI drive (IIRC, there were some with MFM
> to SCSI adaptors), you could hang it on another unix box and just access
> it in raw mode sector-by-sector until you found the password file.
>
While the 3B2 did have optional SCSI support, I don't see it on ours.
As far as I can tell, it is just a MFM disk. It uses the standard two
cables to attach to the mainboard of the 3B2.
> Or -- could it be that someone left the "guest" account password
> free? If so, you can list the password file (it is world readable,
> because it needs to be accessed by lots of programs for information
> about file ownership and the like), so you should be able to see the
> encrypted (really hashed) passwords. You can then copy the one you need
> to another system and start attacking it -- with a program like security
> program like "crack" or "jack the ripper" (which look for weak passwords
> by attacking them, and cracking them if possible), *or* you could
> replace the password on the disk by raw disk edits with the hash of a
> known one. (They are all the same length until recent systems which
> allow other hashing systems.) Just edit in the proper characters one at
> a time, then boot from the disk and log in.
>
I think I tried the guest account, but I should check again. If this
is open, then it would make both the above possible and some exploits
as well.
>
> There may be security holes in the 3B2 like the ones in the 3B1
> (the "mail" icon was one of them), but you will need someone more
> familiar with the 3B2. (I *keep* tying 3B1 when I mean 3B2 -- shows what
> habit my fingers have learned over the years, and not forgotten.
>
I've looked for some sort of remote exploits as well. Since the 3B2
has the ethernet drivers installed we can hook it up to the network
and talk to, say, the telnet daemon. The problem is that searching for
these exploits wasn't successful.
>
> You have my suggestions. What will work depends on what the
> hardware is, and how much other hardware you have on hand.
>
Thanks, but it looks like we will either need the original software or
some AT&T hardware to make this work.
--
Andrew Wesie
Bill Gunshannon
"DoN. Nichols" <dnic...@d-and-d.com> writes:
> On 2009-01-12, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>> In article <slrngml5q6....@katana.d-and-d.com>,
>> "DoN. Nichols" <dnic...@d-and-d.com> writes:
>>> On 2009-01-11, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>
> [ ... ]
>
>>>> The 3B1 and the 3B2 have nothing in common with each other.
>>>
>>> The vendor. And the fact that they both are computers.
>>>
>>> And the fact that they both ran SysVr? OS versions (with various
>>> add-ons. :-)
>>>
>>> And -- I've got a 3B2 external drive housing attached to one of
>>> my 3B1s, to hold both the boot drive (no longer internal) and the second
>>> drive, plus a "floppy tape" drive. Granted, it took a bit of creative
>>> wiring to do that all.
>
> [ ... ]
>
>> I gave some thought to recommending hooking one of the disks up
>> to another computer, but regardless of the possibility of the
>> filesystems being compatable I doubt the controllers used would
>> allow for something other than another member of the 3B2 family
>> (3B12/3B15/3B20) being able to read the disk in its present format.
>> But I suppose there would be no loss in trying.
>
> If it is purely a MFM drive, yes, it would be difficult to
> access from another system.
Mine were, 2 MFM drives on a custom (Western Electric) controller.
>
> But a friend had a 3B2 which had a SCSI interface, and used MFM
> (or were they IDSE) drives on a shared adaptor. I believe that the
> adaptor could handle up to four drives at once, but he only had two on
> it.
I have seen SCSI<->MFM adapters (I actually have one, but have no idea
what it came out of) but the only SCSI I heard about on the 3B's used
pure SCSI disks.
>
> Those drives, *with* the adaptor, could be accessed a sector at
> a time from any SCSI system using the "raw" interface. It would be
> fairly easy to write a C program which would do that and look for a
> sector which started "root:.*:0:0:" (Wildcarding for the password field
> to allow for no password (not the case here),
Actually, you could. drop the password, move the uid and gid and use
the GCOS field to suck up the extra character spaces.
> a real password, or a
> redirection to a shadow password, depending on the age of the system.
Never saw shadow passwords on an 3B I worked with. I don;t think they
were around long enough for that to become the practice.
> If a redirection, then re-do the program to look for "root:.*:" without
> the "0:0:".
>
> Given the age of the system, the length of the password field
> would be constant with the standard password hashing system, making it
> easy to do a raw disk edit on that one sector to replace it with the
> hash of a *known* password. (Anything which changed the length of the
> field would of course require adjusting everything which followed in the
> password file.
Putting in a known hash is probably the easiest way but you could also
do what I said above to get rid of the password entirely.
OK, I'll see your Intergraph and raise you a Tektronix 4300 family
graphics station. Ran not only thier custom stuff but also CPM-86.
I still keep a couple of the magnets fopr biasing the digitizing
tablets around for erasing disks. The magnet was so powerful they
came packed inside a steel pipe when you bought a terminal. :-)
And then, I used to have an Apollo Workstation. Now there's a boat
anchor.
>
>> Funny you
>> should mention SCSI. I actually heard there was a 3Bfamily SCSI
>> controller but I suspect they were even rarer than QBUS or UNIBUS
>> SCSI controllers. Well, maybe they became popular after NCR took
>> over the running of AT&T's 3Bfamily.
>
> Hmm ... I'm afraid that I can't ask the friend about it, as he
> is no longer with us.
>
>> Did you ever hear about the
>> NCR "upgrade" for the 3B2 computer systems? :-)
>
> No -- how bad was it?
As you may or may not know, after the big court fight when AT&T actually
got permission to be in the computer business commercially, they decided
they didn't want to. So they brought in NCR to run that division. NCR's
first move was to "upgrade" the 3B2. Simple upgrade, really. Open case.
dump all 3B2 related parts into garbage can. Insert NCR designed and
manufactured M68K based computer into case. Upgrade completed. :-)
>
>>>> The 3B1 was
>>>> a Convergent Technologies box sold by AT&T and the 3B2 was an AT&T designed
>>>> and manufactured box using the WE32000 CPU.
>>>
>>> Both with the AT&T "Death Star" logo, and similar color schemes,
>>> FWIMBW.
>>
>> Yeah, also sported by the AT&T 6300 family which was made by Olivetti
>> in Italy. And wasn't compatable with anything, not even the IBM PC
>> which was the actual model for the hardware.
>
> And -- it had to have the date routine in the OS patched every
> eight years. The clock chip in that only counted through eight years
> (just enough so it would keep the right years as leap years), and the
> patch added the proper starting point to the eight-year count in the
> chip.
Didn't know about that one but then I never saw one that lasted 8 years. :-)
>
> A friend was still working at a place which used these things
> when the *second* update time came around, and I was able to get the
> patch for her through the help of someone in this very newsgroup. But
> imagine a *business* still using a 16-year old PC sorta clone. :-)
>
>>>> I will look later today, but,
>>>> sadly, I believe I threw all my 3B2 software away years ago when my last
>>>> 3B2 died. If I still have any of them, they yours for the postage.
>>>
>>> And -- if you *don't* have them, it is still possible that he
>>> may be able to use some of the ideas which I covered.
>>
>> He is free to do whatever he wants. It's just that having had a number
>> of them myself I was offering my experience which was that they were
>> not really compatable with anything (that, I am fairly certain, was by
>> design) and by todays standards not really worth a lot of effort.
>
> Well ... I just recently acquired a SGI Indigo 2 (the version
> with the really weird R8000 MIPS processor which had floating point as
> fast as integer math.
I got rid of a pair of Indigos a while ago. I do still have an O2.
Also SPARCStation-II, Ultra Sparc, a couple of original MAC's, a bunch
of newer M68K MAC's, a bunch of PDP-11's and VAXen. Also a bunch of
APPLE ]['s and Tandy computers. And I almost forgot all my 3B1's. One
of these days I hope to actually set up amd operate a computer museum.
>
> One reason for wanting to bring it back to life is that they had
> the only DAT drives which were capable of reading and writing *audio*
> DATs as well as backup tapes -- complete with a graphical sound editing
> program back in 1995. :-)
>
>> While
>> I really liked the processor (and I have the architecture manual here
>> somewhere, I know I kept that for my library) many of the components were
>> did not seem particularly well made and eventually all of mine failed.
>> Compare that to how many other, much older computers are still in
>> almost daily use.
>
> But -- the 3B2 was the porting base for unix for some time. (I
> guess that the higher numbered 3B* systems were a fairly easy port from
> the 3B2 software.
They maintained very good compatability along the whole line. But then,
they had to, they were running the phone system with them and that was
their bread and butter.
>
> And I've still got (but have retired) my first unix box, a
> COSMOS CMS16/UNX (Motorola 8 MHz 68000 CPU with v7 unix in an Intel
> Multibus chassis.) *And* -- I still have the manuals and the 11 8" DSDD
> floppies which made the OS distribution.
My first Unix system was a pre-release Tandy Model 16. I got it when
I was working for Martin Marietta and we were trying to sell a certain
government site on replacing Terak 8510's running UCSD Pascal with
something a bit more business practical. I started this project while
I was in the Army and then worked it from the other side when I got out
and became a contractor. In the end, I got to keep the original machine
we had acquired from Tandy before they started selling them.
>
>> I wish him luck. Oh yeah, I looked. Either I gave away or threw away
>> all the sets of software I had. I suspect gave away as I seldom throw
>> any software out and would more likely have recycled the floppy disks.
>> I do still have the floppy drives, the floppy tapes and I think I may
>> even still have the hard disks here somewhere. I have always wanted to
>> see if I could write a driver to let me use the tape drives on something
>> like a PDP-11.
>
> Did you ever hear of the PDP-11 which ran unix from a DECTAPE?
> Swapping and everything on that one tape drive. :-)
No. And I can't imagine swapping to a DECTAPE at all. But, I do know
there is a version of mini-Unix that runs on the TERAK 8510. LSI-11/02,
28K Words of memory and an 8" floppy. :-) There was a time when Unix
was not nearly as bloated as it later became.
Bill Gunshannon
awe...@gmail.com writes:
> On Jan 10, 11:04 pm, "DoN. Nichols" <dnich...@d-and-d.com> wrote:
>>
>> O.K. I've never worked with a 3B2 -- just the 3B1 -- but what
>> is the floppy size -- 5.25" or 3.5"
>>
> 5.25" Floppy size. It used quad-density disks from what I read. The
> images are 720kb.
80 track, low density (by PC standards). The 80 tracks are what gave
them the 720K.
>>
>> Best there would likely be a 3B1 or another 3B2 with capability
>> to read the disk format. The 3B1 was designed for one MFM drive, but
>> could be modified to handle a second one.
>>
>> If the system used a SCSI drive (IIRC, there were some with MFM
>> to SCSI adaptors), you could hang it on another unix box and just access
>> it in raw mode sector-by-sector until you found the password file.
>>
> While the 3B2 did have optional SCSI support, I don't see it on ours.
> As far as I can tell, it is just a MFM disk. It uses the standard two
> cables to attach to the mainboard of the 3B2.
>> Or -- could it be that someone left the "guest" account password
>> free? If so, you can list the password file (it is world readable,
>> because it needs to be accessed by lots of programs for information
>> about file ownership and the like), so you should be able to see the
>> encrypted (really hashed) passwords. You can then copy the one you need
>> to another system and start attacking it -- with a program like security
>> program like "crack" or "jack the ripper" (which look for weak passwords
>> by attacking them, and cracking them if possible), *or* you could
>> replace the password on the disk by raw disk edits with the hash of a
>> known one. (They are all the same length until recent systems which
>> allow other hashing systems.) Just edit in the proper characters one at
>> a time, then boot from the disk and log in.
>>
> I think I tried the guest account, but I should check again. If this
> is open, then it would make both the above possible and some exploits
> as well.
I looke din my old docs to see if maybe ther ewas some kind of maintenance
account which might have a default password but it looks like even that
far back AT&T knew enough not to do that.
>>
>> There may be security holes in the 3B2 like the ones in the 3B1
>> (the "mail" icon was one of them), but you will need someone more
>> familiar with the 3B2. (I *keep* tying 3B1 when I mean 3B2 -- shows what
>> habit my fingers have learned over the years, and not forgotten.
>>
> I've looked for some sort of remote exploits as well. Since the 3B2
> has the ethernet drivers installed we can hook it up to the network
> and talk to, say, the telnet daemon. The problem is that searching for
> these exploits wasn't successful.
There was no native TCPIP for the 3B2. Unless the previous owner bought
someting like Woolongong there will be no IP on it. Worse still, it only
supported STREAMS. Which may be why they never got a decent IP package.
>>
>> You have my suggestions. What will work depends on what the
>> hardware is, and how much other hardware you have on hand.
>>
> Thanks, but it looks like we will either need the original software or
> some AT&T hardware to make this work.
Well, don't wipe it out yet. I think I know where my copy of the install
docs are. Maybe there is some way to get it into some kind of maintenance
mode (like BSD single user) and then reset the password.
DoN. Nichols
> In article <slrngmleaj....@katana.d-and-d.com>,
> "DoN. Nichols" <dnic...@d-and-d.com> writes:
>> On 2009-01-12, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>>> In article <slrngml5q6....@katana.d-and-d.com>,
>>> "DoN. Nichols" <dnic...@d-and-d.com> writes:
>>>> On 2009-01-11, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
[ ... ]
>>> I gave some thought to recommending hooking one of the disks up
>>> to another computer, but regardless of the possibility of the
>>> filesystems being compatable I doubt the controllers used would
>>> allow for something other than another member of the 3B2 family
>>> (3B12/3B15/3B20) being able to read the disk in its present format.
>>> But I suppose there would be no loss in trying.
>>
>> If it is purely a MFM drive, yes, it would be difficult to
>> access from another system.
>
> Mine were, 2 MFM drives on a custom (Western Electric) controller.
O.K. Any clues as to whether it was implemented as a
MFM<-->SCSI adaptor and a SCSI controller? Or did it plug directly into
the system bus?
There was *one* SCSI controller for the 3B1 which a member of
this newsgroup used to have (and may still have). It was being
developed by his company just about the time the bottom dropped out of
the 3B1 market. So -- he got to take it home and play with it.
I actually used my first MFM drives (a pair of Ampex 27 MB
drives) using a MFM<-->SCSI adaptor and a hand wire-wrapped host adaptor
on a system which was dual-boot -- SSB's DOS-69 and Microware's OS-9
(the *real* one, before Apple claimed the name for the Mac. :-)
OS-9 handled it a lot more gracefully than DOS-69 did, because
when you blend a 6.3 filename format fixed upper case with a lack of
subdirectories, 27 MB becomes *very* unweildy. :-)
Those systems shared four 8" floppys and four 5.26" floppies as
well.
>> But a friend had a 3B2 which had a SCSI interface, and used MFM
>> (or were they IDSE) drives on a shared adaptor. I believe that the
>> adaptor could handle up to four drives at once, but he only had two on
>> it.
>
> I have seen SCSI<->MFM adapters (I actually have one, but have no idea
> what it came out of) but the only SCSI I heard about on the 3B's used
> pure SCSI disks.
O.K. Those would have been the later ones, of course.
>> Those drives, *with* the adaptor, could be accessed a sector at
>> a time from any SCSI system using the "raw" interface. It would be
>> fairly easy to write a C program which would do that and look for a
>> sector which started "root:.*:0:0:" (Wildcarding for the password field
>> to allow for no password (not the case here),
>
> Actually, you could. drop the password, move the uid and gid and use
> the GCOS field to suck up the extra character spaces.
That would work -- it just requires some careful character
counting to get it to come out right. I consider it a bit more
error-sensitive. :-)
>> a real password, or a
>> redirection to a shadow password, depending on the age of the system.
>
> Never saw shadow passwords on an 3B I worked with. I don;t think they
> were around long enough for that to become the practice.
I remember having an open source implementation of shadow
passwords, but I never dared to install it -- too much chance of not
being able to access the system if something screwed up. Kind of like
some company which suggested removing the passwords from the /etc/passwd
file and putting them in a database. That scared the others in
comp.unix.wizards at the time -- though now that is just what the unix
under Mac's OS-X does.
>> If a redirection, then re-do the program to look for "root:.*:" without
>> the "0:0:".
>>
>> Given the age of the system, the length of the password field
>> would be constant with the standard password hashing system, making it
>> easy to do a raw disk edit on that one sector to replace it with the
>> hash of a *known* password. (Anything which changed the length of the
>> field would of course require adjusting everything which followed in the
>> password file.
>
> Putting in a known hash is probably the easiest way but you could also
> do what I said above to get rid of the password entirely.
Agreed!
[ ... ]
>> You want a serious doorstop? Try my Intergraph Interact 32/C.
>> Two 19" monitors mounted on top of a wheeled chassis containing most of
>> the rest, with a big (24x36" IIRC) digitizing tablet hinged to the front
>> with an air cylinder to allow adjusting the angle while a pressure point
>> was pinched. The digitizing tablet and the puck acted as the mouse,
>> with about a dozen buttons on it.
>>
>> It was designed as a graphics workstation, but I didn't have the
>> software to use it as such. I now have the software, but I don't have
>> the license keys to allow me to use the software.
>>
>> The edge of the digitizing tablet had another pair of pressure
>> points to raise or lower the tablet and the monitors as a unit, and
>> another pair to tilt the monitors forward or back to adjust so you
>> could use it comfortably seated low, on a draftsman's stool, or
>> standing.
>
> OK, I'll see your Intergraph and raise you a Tektronix 4300 family
> graphics station.
Was that the one with a QIC tape drive in the right pedestal? I
think that I have the tapes from one hiding somewhere around. :-)
The Intergraph was a significantly larger and heavier beastie.
I had to run it up two deck plank boards to get it into the bed of my
pickup, and those boards were sagging about 6-8" below the centerline
between the ends. :-) I kept expecting them to break. I would guess
about 600 pounds. I've got machine tools which weigh a lot more, and
I'm not sure what the weight of the 6' rack filled with a Sun 3/260 and
three Fujitsu Eagles was. A lot, for sure. :-)
> Ran not only thier custom stuff but also CPM-86.
Ouch! I never knew what the CPU was in the beastie we had
hanging around in the hall for a year or two after we moved into that
building. It finally found an owner to turn it in during one of the
regular property roundups -- someone got tired of having to travel to
our building to verify that it was still there. :-)
> I still keep a couple of the magnets fopr biasing the digitizing
> tablets around for erasing disks. The magnet was so powerful they
> came packed inside a steel pipe when you bought a terminal. :-)
Our computer center had a color laser copier/printer (full
office sized one, not a desktop machine) and someone zapped the boot
floppy with one of those bias magnets. :-)
> And then, I used to have an Apollo Workstation. Now there's a boat
> anchor.
O.K. Not sure of the weight or size for those. I'm impressed
enough with the 60+ pounds of my Sun Blade 2000 machines, and the
somewhat heavier rack-mount version (the Sun Fire 280R).
My Tektronix 6130s were fairly light by comparison. About the
size of the original IBM PC.
>>> Funny you
>>> should mention SCSI. I actually heard there was a 3Bfamily SCSI
>>> controller but I suspect they were even rarer than QBUS or UNIBUS
>>> SCSI controllers. Well, maybe they became popular after NCR took
>>> over the running of AT&T's 3Bfamily.
>>
>> Hmm ... I'm afraid that I can't ask the friend about it, as he
>> is no longer with us.
>>
>>> Did you ever hear about the
>>> NCR "upgrade" for the 3B2 computer systems? :-)
>>
>> No -- how bad was it?
>
> As you may or may not know, after the big court fight when AT&T actually
> got permission to be in the computer business commercially, they decided
> they didn't want to. So they brought in NCR to run that division. NCR's
> first move was to "upgrade" the 3B2. Simple upgrade, really. Open case.
> dump all 3B2 related parts into garbage can. Insert NCR designed and
> manufactured M68K based computer into case. Upgrade completed. :-)
Ouch! The name is the same -- but it won't run the same
software at all. :-(
[ ... ]
>>> Yeah, also sported by the AT&T 6300 family which was made by Olivetti
>>> in Italy. And wasn't compatable with anything, not even the IBM PC
>>> which was the actual model for the hardware.
>>
>> And -- it had to have the date routine in the OS patched every
>> eight years. The clock chip in that only counted through eight years
>> (just enough so it would keep the right years as leap years), and the
>> patch added the proper starting point to the eight-year count in the
>> chip.
>
> Didn't know about that one but then I never saw one that lasted 8 years. :-)
>
>> A friend was still working at a place which used these things
>> when the *second* update time came around, and I was able to get the
>> patch for her through the help of someone in this very newsgroup. But
>> imagine a *business* still using a 16-year old PC sorta clone. :-)
Apparently a few did in this office. She no longer works there,
so I don't know whether they finally upgraed to something else. :-)
Of course, they had no support contract when the problem hit, so
if I had not been reading about it on this newsgroup, they would have
been forced into an upgrade then and there. :-)
[ ... ]
>> Well ... I just recently acquired a SGI Indigo 2 (the version
>> with the really weird R8000 MIPS processor which had floating point as
>> fast as integer math.
>
> I got rid of a pair of Indigos a while ago. I do still have an O2.
> Also SPARCStation-II, Ultra Sparc, a couple of original MAC's, a bunch
> of newer M68K MAC's, a bunch of PDP-11's and VAXen. Also a bunch of
> APPLE ]['s and Tandy computers. And I almost forgot all my 3B1's. One
> of these days I hope to actually set up amd operate a computer museum.
O.K. List time:
1) Altair 680b (raised from a kit). This was the Motorla 6800
CPU version, not the Altair 8800 which used the Intel 8080.
1.5) Technico single-board-computer build on the TI 9800 16-bit CPU.
Never did anything serious with that. Couldn't afford the extra
memory and disk interface for it at the time.
2) SWTP 6800 (SSB DOS-68 quite a few versions as it matured.
3) SWTP 6809 (SSB DOS-69 and OS-9)
4) Cosmos CMS-16/UNX (v7 unix -- Unisoft port with a deadly
inefficient C compiler. It thought that it was dealing with a
PDP-11, and if the PDP-11 didn't have the instruction, it didn't
use it. (The exception were the LINK and ULINK instructions for
creating and destroying a stack frame.)
Eventually was running two Fujitsu 2312K (84 MB 8" SMD interface
drives).
5) AT&T 7300/3B1 family (several over time)
6) Tektronix 6130 (total of two over time)
7) Sun 2/120 (10 MHz 68010)
8) Sun 3/140 (25 MHZ 68020 I think.)
9) Several other Sun3 machines, but never a Sun3X (68030)
9.5) Intergraph Interact 32C
10 SS1+ clone (OPUS)
11 Several Sun SS-2 machines.
12) Sun SS-10
13) Sun SS-5 (two still in service)
14) Sun SS-20
15) Sun Ultra-1
16) Sun Ultra-2s
17) Sun Ultra 60
18) Sun Ultra-5
19) Sun Ultra-10s (currently web servers)
20 Sun Fire 280R
21 Sun Blade 1000 & Sun Blade 2000 machines.
22 Mac Mini (Intel based)
23 ... Not counting the various MS-DOS and Windows machines over time.
I've mostly only listed the machines which I've actually used
for one thing or another.
[ ... ]
>> But -- the 3B2 was the porting base for unix for some time. (I
>> guess that the higher numbered 3B* systems were a fairly easy port from
>> the 3B2 software.
>
> They maintained very good compatability along the whole line. But then,
> they had to, they were running the phone system with them and that was
> their bread and butter.
I wonder what they are using today?
>> And I've still got (but have retired) my first unix box, a
>> COSMOS CMS16/UNX (Motorola 8 MHz 68000 CPU with v7 unix in an Intel
>> Multibus chassis.) *And* -- I still have the manuals and the 11 8" DSDD
>> floppies which made the OS distribution.
>
> My first Unix system was a pre-release Tandy Model 16. I got it when
> I was working for Martin Marietta and we were trying to sell a certain
> government site on replacing Terak 8510's running UCSD Pascal with
> something a bit more business practical. I started this project while
> I was in the Army and then worked it from the other side when I got out
> and became a contractor. In the end, I got to keep the original machine
> we had acquired from Tandy before they started selling them.
Hmm ... The Tandy model 16 was a 68000 based system IIRC. I
wonder who did the port of unix to that one?
>>> I wish him luck. Oh yeah, I looked. Either I gave away or threw away
>>> all the sets of software I had. I suspect gave away as I seldom throw
>>> any software out and would more likely have recycled the floppy disks.
>>> I do still have the floppy drives, the floppy tapes and I think I may
>>> even still have the hard disks here somewhere. I have always wanted to
>>> see if I could write a driver to let me use the tape drives on something
>>> like a PDP-11.
>>
>> Did you ever hear of the PDP-11 which ran unix from a DECTAPE?
>> Swapping and everything on that one tape drive. :-)
>
> No. And I can't imagine swapping to a DECTAPE at all.
It did it! It was slow (of course), but it was mostly a
proof-of-principle thing. :-)
> But, I do know
> there is a version of mini-Unix that runs on the TERAK 8510. LSI-11/02,
> 28K Words of memory and an 8" floppy. :-) There was a time when Unix
> was not nearly as bloated as it later became.
O.K I have the LSI-11 two-wide card cage full of cards
(including the floppy interface) and a single matching floppy drive to
build one.
I also have a Bridgeport BOSS-3 CNC mill with a serious case of
electronics Altzheimer's built on a quad-wide LSI-11. That is coming
out, and being replaced with a linux-based EMC package.
DoN. Nichols
> On Jan 10, 11:04 pm, "DoN. Nichols" <dnich...@d-and-d.com> wrote:
>>
>> O.K. I've never worked with a 3B2 -- just the 3B1 -- but what
>> is the floppy size -- 5.25" or 3.5"
>>
> 5.25" Floppy size. It used quad-density disks from what I read. The
> images are 720kb.
O.K. Then you need the 80 track double sided floppy drives for
those.
Hmm ... maybe enough space to boot a small kernel and a shell to
give you access to the drive -- even raw access if the right tools are
present.
>> Best there would likely be a 3B1 or another 3B2 with capability
>> to read the disk format. The 3B1 was designed for one MFM drive, but
>> could be modified to handle a second one.
>>
>> If the system used a SCSI drive (IIRC, there were some with MFM
>> to SCSI adaptors), you could hang it on another unix box and just access
>> it in raw mode sector-by-sector until you found the password file.
>>
>
> While the 3B2 did have optional SCSI support, I don't see it on ours.
O.K. That would have been nice, if you had it.
> As far as I can tell, it is just a MFM disk. It uses the standard two
> cables to attach to the mainboard of the 3B2.
O.K. You would need to know a lot of parameters to be able to
access the disk raw from another systems -- but maybe a linux system
could do it -- some had filesystem support for the 3B1 at least, and
likely the 3B2 as well.
>> Or -- could it be that someone left the "guest" account password
>> free? If so, you can list the password file (it is world readable,
[ ... ]
> I think I tried the guest account, but I should check again. If this
> is open, then it would make both the above possible and some exploits
> as well.
O.K.
>>
>> There may be security holes in the 3B2 like the ones in the 3B1
>> (the "mail" icon was one of them), but you will need someone more
>> familiar with the 3B2. (I *keep* tying 3B1 when I mean 3B2 -- shows what
>> habit my fingers have learned over the years, and not forgotten.
>>
>
> I've looked for some sort of remote exploits as well. Since the 3B2
> has the ethernet drivers installed we can hook it up to the network
> and talk to, say, the telnet daemon. The problem is that searching for
> these exploits wasn't successful.
Hmm ... can you telnet in on port 25 (smtp)? Sendmail has had a
*lot* of security holes through the years. :-)
Or ftp log in as guest and download the /etc/passwd file, which
is still world readable. A guest account would not work for replacing
the file, but for reading it, yes.
>> You have my suggestions. What will work depends on what the
>> hardware is, and how much other hardware you have on hand.
>>
>
> Thanks, but it looks like we will either need the original software or
> some AT&T hardware to make this work.
Or someone willing to dig into the raw MFM drive. IIRC, the 3B1
at least put a description of the format of the disk in the first
sector, so you could get that information and use it for trying to
access later parts.
Ideally, you would want to find a hardware write-protect jumper
for the drive while you are doing this, so you would not corrupt it in
any way.
Good Luck,
Bill Gunshannon
"DoN. Nichols" <dnic...@d-and-d.com> writes:
> On 2009-01-12, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>> In article <slrngmleaj....@katana.d-and-d.com>,
>> "DoN. Nichols" <dnic...@d-and-d.com> writes:
>>> On 2009-01-12, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>>>> In article <slrngml5q6....@katana.d-and-d.com>,
>>>> "DoN. Nichols" <dnic...@d-and-d.com> writes:
>>>>> On 2009-01-11, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>
> [ ... ]
>
>>>> I gave some thought to recommending hooking one of the disks up
>>>> to another computer, but regardless of the possibility of the
>>>> filesystems being compatable I doubt the controllers used would
>>>> allow for something other than another member of the 3B2 family
>>>> (3B12/3B15/3B20) being able to read the disk in its present format.
>>>> But I suppose there would be no loss in trying.
>>>
>>> If it is purely a MFM drive, yes, it would be difficult to
>>> access from another system.
>>
>> Mine were, 2 MFM drives on a custom (Western Electric) controller.
>
> O.K. Any clues as to whether it was implemented as a
> MFM<-->SCSI adaptor and a SCSI controller? Or did it plug directly into
> the system bus?
Pure MFM. SCSI came much later as an add on card. Doesn't mean people
didn't then put MFM on the SCSI controller but it sure wouldn't make
much sense to do so. Biggest MFM disk was ~70 meg. Not much space,
even in those days. I saw a 3B2 running as a USENET News Server. Not
going to do that long with only 2 70meg disks when the OS easily takes
up one whole disk. :-)
>
> There was *one* SCSI controller for the 3B1 which a member of
> this newsgroup used to have (and may still have). It was being
> developed by his company just about the time the bottom dropped out of
> the 3B1 market. So -- he got to take it home and play with it.
I heard about this, but never saw one available. Of course, this would
not have helped the 3B2 as they shared no common bus. The SCSI card
for the 3B2 was definitely a commercial offering. I just can't remember
if AT&T was the maker or even the marketer.
>
> I actually used my first MFM drives (a pair of Ampex 27 MB
> drives) using a MFM<-->SCSI adaptor and a hand wire-wrapped host adaptor
I thought you had been doing this a lot longer than that. I still have
(and use) my first MFM disk. A whopping 12M which was actually rather
large at the time, 5 meg being much more common. Luckily, I didn't pay
for it. It easily cost more than the computer it was connected to.
> on a system which was dual-boot -- SSB's DOS-69 and Microware's OS-9
> (the *real* one, before Apple claimed the name for the Mac. :-)
I thought Apple went straight from SYSTEM7 to OS-X skipping over things
like OS-9 (which was already trademarked). Of course, Microware is all
the way up to OS-9000 now. :-) I still have systems running OS9. I
just wish they would open source OS9 and OS9-68K, but I doubt it will
ever happen.
>
> OS-9 handled it a lot more gracefully than DOS-69 did, because
> when you blend a 6.3 filename format fixed upper case with a lack of
> subdirectories, 27 MB becomes *very* unweildy. :-)
How about early MSDOS? I had a NEC APC. Had 2 quad-density 8" drives.
1.25M each. Ever heard of "Extended Directory Entries"? You type DIR.
The system prints out all the entries in the normal directory. Then
comes "The Extended Directory Entries". Move head to directory. Pointer
extended directory. Move head to extended directory. print one entry.
Repeat until all entries printed. Takes about 1 minute per entry. :-)
Makes CP/M and RT-11 look like real screamers.
>
> Those systems shared four 8" floppys and four 5.26" floppies as
> well.
OS/9 always did a good job of disk handling. Could easily handle many drives
all in different formats. A really good OS.
>
>>> But a friend had a 3B2 which had a SCSI interface, and used MFM
>>> (or were they IDSE) drives on a shared adaptor. I believe that the
>>> adaptor could handle up to four drives at once, but he only had two on
>>> it.
>>
>> I have seen SCSI<->MFM adapters (I actually have one, but have no idea
>> what it came out of) but the only SCSI I heard about on the 3B's used
>> pure SCSI disks.
>
> O.K. Those would have been the later ones, of course.
>
>>> Those drives, *with* the adaptor, could be accessed a sector at
>>> a time from any SCSI system using the "raw" interface. It would be
>>> fairly easy to write a C program which would do that and look for a
>>> sector which started "root:.*:0:0:" (Wildcarding for the password field
>>> to allow for no password (not the case here),
>>
>> Actually, you could. drop the password, move the uid and gid and use
>> the GCOS field to suck up the extra character spaces.
>
> That would work -- it just requires some careful character
> counting to get it to come out right. I consider it a bit more
> error-sensitive. :-)
>
>>> a real password, or a
>>> redirection to a shadow password, depending on the age of the system.
>>
>> Never saw shadow passwords on an 3B I worked with. I don;t think they
>> were around long enough for that to become the practice.
>
> I remember having an open source implementation of shadow
> passwords,
Yeah, was passed out in comp.sources.misc. But we didn't call it
"Open Source" in those days. We just wrote code and gave it away.
Everyone knows Stallman invented Open Source.
> but I never dared to install it -- too much chance of not
> being able to access the system if something screwed up. Kind of like
> some company which suggested removing the passwords from the /etc/passwd
> file and putting them in a database. That scared the others in
> comp.unix.wizards at the time -- though now that is just what the unix
> under Mac's OS-X does.
Well, the first shadow password suite was in comp.sources.misc volume 26
which was lat 1991 and the 3B line died in 1990 so it is pretty safe bet
that AT&T never officially adopted it.
Nope. All the software it needed as a graphics design station was in
firmware. But you could boot it out of this with CPM-86 and that even
came with Fortran. Had a pair of 8" (big clunky Shugart's) disks.
>
> The Intergraph was a significantly larger and heavier beastie.
> I had to run it up two deck plank boards to get it into the bed of my
> pickup, and those boards were sagging about 6-8" below the centerline
> between the ends. :-) I kept expecting them to break. I would guess
> about 600 pounds. I've got machine tools which weigh a lot more, and
> I'm not sure what the weight of the 6' rack filled with a Sun 3/260 and
> three Fujitsu Eagles was. A lot, for sure. :-)
I have a real truck now, but when I thin about what I moved using my
old Volvo 200 series station wagon.... Once made three trips to Jersey
and came home with the car completely jammed to the ceiling (even had
one on the pasengers seat) with RA80/RA81 disk drives.
>
>> Ran not only thier custom stuff but also CPM-86.
>
> Ouch! I never knew what the CPU was in the beastie we had
> hanging around in the hall for a year or two after we moved into that
> building. It finally found an owner to turn it in during one of the
> regular property roundups -- someone got tired of having to travel to
> our building to verify that it was still there. :-)
I have picked up a lot of gear that way. I got the Tek when we had a
visit from and auditor who wanted to know why we were paying to store
it. He said dump it and we did. Right into the back of that infamous
Volvo station wagon. :-) That also how I got all my Teraks.
>
>> I still keep a couple of the magnets fopr biasing the digitizing
>> tablets around for erasing disks. The magnet was so powerful they
>> came packed inside a steel pipe when you bought a terminal. :-)
>
> Our computer center had a color laser copier/printer (full
> office sized one, not a desktop machine) and someone zapped the boot
> floppy with one of those bias magnets. :-)
Works good, doesn't it? :-)
>
>> And then, I used to have an Apollo Workstation. Now there's a boat
>> anchor.
>
> O.K. Not sure of the weight or size for those. I'm impressed
> enough with the 60+ pounds of my Sun Blade 2000 machines, and the
> somewhat heavier rack-mount version (the Sun Fire 280R).
I would have put it in the 500-600 lb catagory. I had to dismantle it
to bring it home. Made a great little space heater int he winter.
Couldn't run it in the summer. Had an HDA even bigger than an RA80.
>
> My Tektronix 6130s were fairly light by comparison. About the
> size of the original IBM PC.
>
>>>> Funny you
>>>> should mention SCSI. I actually heard there was a 3Bfamily SCSI
>>>> controller but I suspect they were even rarer than QBUS or UNIBUS
>>>> SCSI controllers. Well, maybe they became popular after NCR took
>>>> over the running of AT&T's 3Bfamily.
>>>
>>> Hmm ... I'm afraid that I can't ask the friend about it, as he
>>> is no longer with us.
>>>
>>>> Did you ever hear about the
>>>> NCR "upgrade" for the 3B2 computer systems? :-)
>>>
>>> No -- how bad was it?
>>
>> As you may or may not know, after the big court fight when AT&T actually
>> got permission to be in the computer business commercially, they decided
>> they didn't want to. So they brought in NCR to run that division. NCR's
>> first move was to "upgrade" the 3B2. Simple upgrade, really. Open case.
>> dump all 3B2 related parts into garbage can. Insert NCR designed and
>> manufactured M68K based computer into case. Upgrade completed. :-)
>
> Ouch! The name is the same -- but it won't run the same
> software at all. :-(
Well, NCR already had a line of computers and when AT&T acquired them they
became the AT&T Computer Division so it was obvious which way they would
go. That, and at that time the small unix system market was pretty much
M68K based. Unisys, Prime, NCR, Convergent, Tandy, all the real players.
That's what the IBM PC was supposed to be, but that's another story.
Silly question. I have no doubt that the phone system is PC based.
At least that which isn't running embeded CPU's.
>
>>> And I've still got (but have retired) my first unix box, a
>>> COSMOS CMS16/UNX (Motorola 8 MHz 68000 CPU with v7 unix in an Intel
>>> Multibus chassis.) *And* -- I still have the manuals and the 11 8" DSDD
>>> floppies which made the OS distribution.
>>
>> My first Unix system was a pre-release Tandy Model 16. I got it when
>> I was working for Martin Marietta and we were trying to sell a certain
>> government site on replacing Terak 8510's running UCSD Pascal with
>> something a bit more business practical. I started this project while
>> I was in the Army and then worked it from the other side when I got out
>> and became a contractor. In the end, I got to keep the original machine
>> we had acquired from Tandy before they started selling them.
>
> Hmm ... The Tandy model 16 was a 68000 based system IIRC. I
> wonder who did the port of unix to that one?
Microsoft. It was originally SYS III based Xenix. The original
documentation I got (because it was pre-release machine) was a mixture
of original AT&T Unix docs and Xeroxed MS Xenix docs.
>
>>>> I wish him luck. Oh yeah, I looked. Either I gave away or threw away
>>>> all the sets of software I had. I suspect gave away as I seldom throw
>>>> any software out and would more likely have recycled the floppy disks.
>>>> I do still have the floppy drives, the floppy tapes and I think I may
>>>> even still have the hard disks here somewhere. I have always wanted to
>>>> see if I could write a driver to let me use the tape drives on something
>>>> like a PDP-11.
>>>
>>> Did you ever hear of the PDP-11 which ran unix from a DECTAPE?
>>> Swapping and everything on that one tape drive. :-)
>>
>> No. And I can't imagine swapping to a DECTAPE at all.
>
> It did it! It was slow (of course), but it was mostly a
> proof-of-principle thing. :-)
>
>> But, I do know
>> there is a version of mini-Unix that runs on the TERAK 8510. LSI-11/02,
>> 28K Words of memory and an 8" floppy. :-) There was a time when Unix
>> was not nearly as bloated as it later became.
>
> O.K I have the LSI-11 two-wide card cage full of cards
> (including the floppy interface) and a single matching floppy drive to
> build one.
To build one what? Terak requires a quad wide backplane as the graphics
and memory all on one piggy-backed double board quad wide module.
>
> I also have a Bridgeport BOSS-3 CNC mill with a serious case of
> electronics Altzheimer's built on a quad-wide LSI-11. That is coming
> out, and being replaced with a linux-based EMC package.
Not surprised. I once sent a couple of 11/02 modules to a guy out west
to fix his Bridgeport. I'll bet there are a bunch of them running in
all the speed shops we have around here.
All the best.
DoN. Nichols
> In article <slrngmo6kh....@katana.d-and-d.com>,
> "DoN. Nichols" <dnic...@d-and-d.com> writes:
>> On 2009-01-12, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
[ ... ]
>>> Mine were, 2 MFM drives on a custom (Western Electric) controller.
>>
>> O.K. Any clues as to whether it was implemented as a
>> MFM<-->SCSI adaptor and a SCSI controller? Or did it plug directly into
>> the system bus?
>
> Pure MFM. SCSI came much later as an add on card. Doesn't mean people
> didn't then put MFM on the SCSI controller but it sure wouldn't make
> much sense to do so. Biggest MFM disk was ~70 meg.
Actually, the biggest MFM 5.25" full height drive was the Maxtor
and Priam 190 MB (raw), which formatted to 160 MB on the 3B1.
> Not much space,
> even in those days. I saw a 3B2 running as a USENET News Server. Not
> going to do that long with only 2 70meg disks when the OS easily takes
> up one whole disk. :-)
Well ... you could strip out a lot of the OS if it were only to
be a news server. You would need to keep uucp (unless you were running
NNTP instead), and you would need to keep at least one editor, but a lot
of the application programs (including the Documenter's Workbench) could
be stripped out. And blowing away the Man pages would make a lot of
room.
he 3B1 never had on-line manuals. Add to that the fact that the
default editor if you clicked on a file was "ed", and the only
documentation for ed was in the development set, which also got you vi
so you would not use ed by choice at all. :-) Of course, the assumption
was that Mr. Businessman, who had it on his desk, would have installed a
word processing package which would replace the ed as the default
editor. I can just imagine a businessman trying to find out how to get
out of a program which simply prompts with a '?'. :-) I had other
manuals from other versions when I got my first 7300, so I had a chance
to deal with that.
>> There was *one* SCSI controller for the 3B1 which a member of
>> this newsgroup used to have (and may still have). It was being
>> developed by his company just about the time the bottom dropped out of
>> the 3B1 market. So -- he got to take it home and play with it.
>
> I heard about this, but never saw one available.
Not one *model*. One physical controller, no more ever made.
:-)
> Of course, this would
> not have helped the 3B2 as they shared no common bus.
Agreed.
> The SCSI card
> for the 3B2 was definitely a commercial offering. I just can't remember
> if AT&T was the maker or even the marketer.
O.K.
>>
>> I actually used my first MFM drives (a pair of Ampex 27 MB
>> drives) using a MFM<-->SCSI adaptor and a hand wire-wrapped host adaptor
>
> I thought you had been doing this a lot longer than that.
I was. I started with a pair of 5.6 MB drives by IMI (IIRC),
which used a weird controller card to talk to up to two drives. The
drives were not MFM (or at least not ST506 interface). When I
overflowed those, I got the first Ampex 27 MB MFM drive to add one, with
a SCSI controller card, and when that got near full, I picked up another
Ampex 27 MB drive to fill up that controller. Lots of wire-wrapped
interfaces and home brewed drivers. I first wrote and tested a driver
on the SSB DOS-69, and once that was known to work, I attacked writing
the driver for OS-9, and forgot about using 5.6 MB on a SSB OS, let
alone using a 27MB one on there. :-)
> I still have
> (and use) my first MFM disk. A whopping 12M which was actually rather
> large at the time, 5 meg being much more common. Luckily, I didn't pay
> for it. It easily cost more than the computer it was connected to.
I still have both the 5.6 MB drives and the 27 MB drives, and
may someday fire that system up again.
>> on a system which was dual-boot -- SSB's DOS-69 and Microware's OS-9
>> (the *real* one, before Apple claimed the name for the Mac. :-)
>
> I thought Apple went straight from SYSTEM7 to OS-X skipping over things
> like OS-9 (which was already trademarked).
Nope -- they had OS-8 (which did not bother me) and OS-9
(different punctuation between "OS" and "9" than Microware used, and
they and the lawyers, so they could get away with it. :-( This did lead
to a lot of debates with a friend in Minnesotta (never actually saw him,
just e-mail exchanges). I insisted on calling the Apple version OS-IX.
> Of course, Microware is all
> the way up to OS-9000 now. :-) I still have systems running OS9. I
> just wish they would open source OS9 and OS9-68K, but I doubt it will
> ever happen.
That would be nice. It would give me something to run on a set
of VME cards which include a 68K CPU (68020 IIRC) and a floppy
interface. Until I get an OS, I won't bother hanging power supplies on
the card cage. :-)
>> OS-9 handled it a lot more gracefully than DOS-69 did, because
>> when you blend a 6.3 filename format fixed upper case with a lack of
>> subdirectories, 27 MB becomes *very* unwieldy. :-)
>
> How about early MSDOS?
I didn't touch a MS-DOS machine until they had subdirectories.
And then I would still have preferred to not do so, but work insisted.
(I later wound up on the unix/network admin team and got plenty of unix
then. :-)
> I had a NEC APC. Had 2 quad-density 8" drives.
> 1.25M each. Ever heard of "Extended Directory Entries"? You type DIR.
> The system prints out all the entries in the normal directory. Then
> comes "The Extended Directory Entries". Move head to directory. Pointer
> extended directory. Move head to extended directory. print one entry.
> Repeat until all entries printed. Takes about 1 minute per entry. :-)
> Makes CP/M and RT-11 look like real screamers.
:-)
>> Those systems shared four 8" floppys and four 5.26" floppies as
>> well.
>
> OS/9 always did a good job of disk handling. Could easily handle many drives
> all in different formats. A really good OS.
Right. I even wrote a modified floppy driver for it to handle
the Radio Shack Color Computer OS-9 format -- which had to skip over the
Radio Shack directory which was always in the middle tracks. :-) I did
this so I could use the more affordable C compiler from them instead of
paying Microware the extra bucks for normal floppys. (I also had to do a
little tweaking to the binaries to keep it from forcing the source to
live on a different disk than the compiler did. :-)
[ ... ]
>>>> a real password, or a
>>>> redirection to a shadow password, depending on the age of the system.
>>>
>>> Never saw shadow passwords on an 3B I worked with. I don;t think they
>>> were around long enough for that to become the practice.
>>
>> I remember having an open source implementation of shadow
>> passwords,
>
> Yeah, was passed out in comp.sources.misc.
Yep. When it came out, I was using (remotely) a BBN C70
which was the e-mail system for the area where I worked. 10-bit bytes,
20-bit words, 40-bit longs. :-) And some of them had no unsigned (or was
it no signed) version. :-)
It really blew the normal "compress" program out of the water,
but the configuration for another compression program (which I got from
the OS-9 User's Group Library) could be tuned to deal with that, so it
would work happily.
Actually, the normal LZW "compress" gave no trouble -- until it
was time to *uncompress* a binary. It could fill several disks.
> But we didn't call it
> "Open Source" in those days. We just wrote code and gave it away.
> Everyone knows Stallman invented Open Source.
:-)
>> but I never dared to install it -- too much chance of not
>> being able to access the system if something screwed up. Kind of like
>> some company which suggested removing the passwords from the /etc/passwd
>> file and putting them in a database. That scared the others in
>> comp.unix.wizards at the time -- though now that is just what the unix
>> under Mac's OS-X does.
>
> Well, the first shadow password suite was in comp.sources.misc volume 26
> which was lat 1991 and the 3B line died in 1990 so it is pretty safe bet
> that AT&T never officially adopted it.
O.K. That does not mean that someone has not implemented it
from those sources -- perhaps even in the machine which started this
thread. :-)
[ ... ]
>>> OK, I'll see your Intergraph and raise you a Tektronix 4300 family
>>> graphics station.
>>
>> Was that the one with a QIC tape drive in the right pedestal? I
>> think that I have the tapes from one hiding somewhere around. :-)
>
> Nope. All the software it needed as a graphics design station was in
> firmware. But you could boot it out of this with CPM-86 and that even
> came with Fortran. Had a pair of 8" (big clunky Shugart's) disks.
O.K. The SA8002 and SA8004 (two and four surfaces, resulting in
10 MB or 20MB? My first machine actually came with the drivers for that,
but with a 20 MB drive you could not put the man pages on. :-)
>>
>> The Intergraph was a significantly larger and heavier beastie.
>> I had to run it up two deck plank boards to get it into the bed of my
>> pickup, and those boards were sagging about 6-8" below the centerline
>> between the ends. :-) I kept expecting them to break. I would guess
>> about 600 pounds. I've got machine tools which weigh a lot more, and
>> I'm not sure what the weight of the 6' rack filled with a Sun 3/260 and
>> three Fujitsu Eagles was. A lot, for sure. :-)
>
> I have a real truck now, but when I thin about what I moved using my
> old Volvo 200 series station wagon.... Once made three trips to Jersey
> and came home with the car completely jammed to the ceiling (even had
> one on the pasengers seat) with RA80/RA81 disk drives.
Was there any clearance between the frame bumpers and the
axle? :-)
>>> Ran not only thier custom stuff but also CPM-86.
>>
>> Ouch! I never knew what the CPU was in the beastie we had
>> hanging around in the hall for a year or two after we moved into that
>> building. It finally found an owner to turn it in during one of the
>> regular property roundups -- someone got tired of having to travel to
>> our building to verify that it was still there. :-)
>
> I have picked up a lot of gear that way. I got the Tek when we had a
> visit from and auditor who wanted to know why we were paying to store
> it. He said dump it and we did. Right into the back of that infamous
> Volvo station wagon. :-) That also how I got all my Teraks.
I couldn't get things that way. This was the government, and we
were forced to do paperwork to turn it in so it could be sold for $5.00
at a surplus sale. :-) The paperwork cost more than the income from
it. :-)
>>> I still keep a couple of the magnets fopr biasing the digitizing
>>> tablets around for erasing disks. The magnet was so powerful they
>>> came packed inside a steel pipe when you bought a terminal. :-)
>>
>> Our computer center had a color laser copier/printer (full
>> office sized one, not a desktop machine) and someone zapped the boot
>> floppy with one of those bias magnets. :-)
>
> Works good, doesn't it? :-)
Yep!
>>> And then, I used to have an Apollo Workstation. Now there's a boat
>>> anchor.
>>
>> O.K. Not sure of the weight or size for those. I'm impressed
>> enough with the 60+ pounds of my Sun Blade 2000 machines, and the
>> somewhat heavier rack-mount version (the Sun Fire 280R).
>
> I would have put it in the 500-600 lb catagory. I had to dismantle it
> to bring it home. Made a great little space heater int he winter.
> Couldn't run it in the summer. Had an HDA even bigger than an RA80.
O.K. that sounds similar to the Intergraph -- except that I
could drive it home -- with a 3/4 ton pickup truck. :-)
>>>>> NCR "upgrade" for the 3B2 computer systems? :-)
>>>>
>>>> No -- how bad was it?
>>>
>>> As you may or may not know, after the big court fight when AT&T actually
>>> got permission to be in the computer business commercially, they decided
>>> they didn't want to. So they brought in NCR to run that division. NCR's
>>> first move was to "upgrade" the 3B2. Simple upgrade, really. Open case.
>>> dump all 3B2 related parts into garbage can. Insert NCR designed and
>>> manufactured M68K based computer into case. Upgrade completed. :-)
>>
>> Ouch! The name is the same -- but it won't run the same
>> software at all. :-(
>
> Well, NCR already had a line of computers and when AT&T acquired them they
> became the AT&T Computer Division so it was obvious which way they would
> go. That, and at that time the small unix system market was pretty much
> M68K based. Unisys, Prime, NCR, Convergent, Tandy, all the real players.
Was Sun in business by then? They started with the 68K
processors. My 1/120 had a 10 MHz 68010 (same as the 3B1, but BSD
flavor). I *think* that the original SUN had the 68000 plain vanilla,
like my Coamos CMS-16/UNX.
> That's what the IBM PC was supposed to be, but that's another story.
That would have been an interesting twist to history. I wonder
where things would be if that had happened?
[ ... ]
>>> I got rid of a pair of Indigos a while ago. I do still have an O2.
>>> Also SPARCStation-II, Ultra Sparc, a couple of original MAC's, a bunch
>>> of newer M68K MAC's, a bunch of PDP-11's and VAXen. Also a bunch of
>>> APPLE ]['s and Tandy computers. And I almost forgot all my 3B1's. One
>>> of these days I hope to actually set up amd operate a computer museum.
>>
>> O.K. List time:
>>
>> 1) Altair 680b (raised from a kit). This was the Motorla 6800
>> CPU version, not the Altair 8800 which used the Intel 8080.
[ ... ]
>> 22 Mac Mini (Intel based)
>>
>> 23 ... Not counting the various MS-DOS and Windows machines over time.
>>
>> I've mostly only listed the machines which I've actually used
>> for one thing or another.
And I missed the Emco-Maier Compact-5/CNC -- a little desktop
CNC lathe -- controlled by a 6502. :-)
[ ... ]
>>> They maintained very good compatability along the whole line. But then,
>>> they had to, they were running the phone system with them and that was
>>> their bread and butter.
>>
>> I wonder what they are using today?
>
> Silly question. I have no doubt that the phone system is PC based.
> At least that which isn't running embeded CPU's.
Ouch!
[ ... ]
>> Hmm ... The Tandy model 16 was a 68000 based system IIRC. I
>> wonder who did the port of unix to that one?
>
> Microsoft. It was originally SYS III based Xenix. The original
> documentation I got (because it was pre-release machine) was a mixture
> of original AT&T Unix docs and Xeroxed MS Xenix docs.
O.K.
[ ... ]
>>> But, I do know
>>> there is a version of mini-Unix that runs on the TERAK 8510. LSI-11/02,
>>> 28K Words of memory and an 8" floppy. :-) There was a time when Unix
>>> was not nearly as bloated as it later became.
>>
>> O.K I have the LSI-11 two-wide card cage full of cards
>> (including the floppy interface) and a single matching floppy drive to
>> build one.
>
> To build one what? Terak requires a quad wide backplane as the graphics
> and memory all on one piggy-backed double board quad wide module.
O.K. Out of reach of the hardware which I have, then.
>>
>> I also have a Bridgeport BOSS-3 CNC mill with a serious case of
>> electronics Altzheimer's built on a quad-wide LSI-11. That is coming
>> out, and being replaced with a linux-based EMC package.
>
> Not surprised. I once sent a couple of 11/02 modules to a guy out west
> to fix his Bridgeport. I'll bet there are a bunch of them running in
> all the speed shops we have around here.
As far as I can tell, they had custom firmware on the chips as
well.
> All the best.
And to you,
Thad Floryan
> [...]
> Yeah, was passed out in comp.sources.misc. But we didn't call it
> "Open Source" in those days. We just wrote code and gave it away.
> Everyone knows Stallman invented Open Source.
Oh? I would politely disagree. :-)
Back in the 1960s we had clearly the model of what is today's
open source. The tapes would be in a cabinet, anyone was free
to copy or use the tapes, make changes, write a new tape, and
place that tape in the cabinet for others to use or learn from.
Do a Google search on "UCB SDS-930" or "Project Genie" or visit:
<http://en.wikipedia.org/wiki/Project_Genie>
Genie was started and funded by ARPA, the same folks who begat
ARPANET and, later, circa 1975, funded Stallman's EMACS project
which was also open source.
I have been using EMACS since 1976 or so and the oldest EMACS
manual I could find in my files was handed to me by RMS in
John McCarthy's office at Stanford early September 1980. A
recent scan (2008) of that manual can be seen here:
<http://thadlabs.com/FILES/Emacs-150_1980.09.05.pdf>
9.1 MB, 210 pages. I have a copy of the tape in my files
but no way to read it.
Bill Gunshannon
"DoN. Nichols" <dnic...@d-and-d.com> writes:
> On 2009-01-13, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>> In article <slrngmo6kh....@katana.d-and-d.com>,
>> "DoN. Nichols" <dnic...@d-and-d.com> writes:
>>> On 2009-01-12, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>
> [ ... ]
>
>>>> Mine were, 2 MFM drives on a custom (Western Electric) controller.
>>>
>>> O.K. Any clues as to whether it was implemented as a
>>> MFM<-->SCSI adaptor and a SCSI controller? Or did it plug directly into
>>> the system bus?
>>
>> Pure MFM. SCSI came much later as an add on card. Doesn't mean people
>> didn't then put MFM on the SCSI controller but it sure wouldn't make
>> much sense to do so. Biggest MFM disk was ~70 meg.
>
> Actually, the biggest MFM 5.25" full height drive was the Maxtor
> and Priam 190 MB (raw), which formatted to 160 MB on the 3B1.
Never saw one that big, but the limit I was thinking of was probably on
the controller and not the actual disk now that I think about it. Wasn't
the 3B1 limited to 70M? I know the Tandy was. I once built a system that
had 4 70M drives, all the memory you could cram in and 6 additional serial
ports. That was considered a killer machine. The serial ports were hooked
up to Sytek Netmork Ports (Broadband Network!) and we ran UNaXcess BBS on
it. Even had a gateway to real USENET. Work is never like that anymore.
>
>> Not much space,
>> even in those days. I saw a 3B2 running as a USENET News Server. Not
>> going to do that long with only 2 70meg disks when the OS easily takes
>> up one whole disk. :-)
>
> Well ... you could strip out a lot of the OS if it were only to
> be a news server.
Actually, with the 3B2 (actually with anything out of AT&T) you don't
strip it to get work done, you add all the stuff they made optional.
Like a compiler!!
> You would need to keep uucp (unless you were running
> NNTP instead),
At that time there was no NNTP all of USENET was still UUCP.
UUCP: {philabs}\
{phri } >!trotter.usma.edu!bill
{sunybcs}/
Remember the group mail.maps? And, the 3B2 had no TCPIP. Eventually
Woolongong did one but AT&T never did that I was aware of. That was
a Berkeley thing, not SYS V.
> and you would need to keep at least one editor, but a lot
> of the application programs (including the Documenter's Workbench) could
> be stripped out. And blowing away the Man pages would make a lot of
> room.
Tough to do when your news server is also a general purpose machine.
USENET (especially News) was a lot samller in those days. We didn't
even have a USENET 500. :-)
>
> he 3B1 never had on-line manuals. Add to that the fact that the
> default editor if you clicked on a file was "ed", and the only
> documentation for ed was in the development set, which also got you vi
> so you would not use ed by choice at all. :-) Of course, the assumption
> was that Mr. Businessman, who had it on his desk,
I doubt any businessman ever had a 3B2 "on his desk". He might have used
it for a desk, but "on his desk" would have left no room for even his
phone. :-) Actually, I imagine most of them resided in computer rooms.
They were big, noisy, generated heat and certainly offered no kind of
built in terminal capability anyway. But we had termcap so just about any
terminal in the world worked. I kinda miss my TeleVideo-950.
> would have installed a
> word processing package which would replace the ed as the default
> editor. I can just imagine a businessman trying to find out how to get
> out of a program which simply prompts with a '?'. :-) I had other
> manuals from other versions when I got my first 7300, so I had a chance
> to deal with that.
Actually, I can't imagine a businessman using a 3B2 at all. :-) But then,
that wasn't the target market.
Yeah, I have a couple of QBUS M68K cards that would make great OS9-68K
machines. And, it's ROMable!!
I still have Tandy Color Computers. The only thing I ever ran onthem was
OS-9. :-)
>
> [ ... ]
>
>>>>> a real password, or a
>>>>> redirection to a shadow password, depending on the age of the system.
>>>>
>>>> Never saw shadow passwords on an 3B I worked with. I don;t think they
>>>> were around long enough for that to become the practice.
>>>
>>> I remember having an open source implementation of shadow
>>> passwords,
>>
>> Yeah, was passed out in comp.sources.misc.
>
> Yep. When it came out, I was using (remotely) a BBN C70
> which was the e-mail system for the area where I worked. 10-bit bytes,
> 20-bit words, 40-bit longs. :-) And some of them had no unsigned (or was
> it no signed) version. :-)
>
> It really blew the normal "compress" program out of the water,
Didn't take much. There were many machines that couldnot do the higher
compression ratios so you frequently found yourself unable to uncompress
something you got from USENET.
> but the configuration for another compression program (which I got from
> the OS-9 User's Group Library) could be tuned to deal with that, so it
> would work happily.
>
> Actually, the normal LZW "compress" gave no trouble -- until it
> was time to *uncompress* a binary. It could fill several disks.
>
>> But we didn't call it
>> "Open Source" in those days. We just wrote code and gave it away.
>> Everyone knows Stallman invented Open Source.
>
> :-)
>
>>> but I never dared to install it -- too much chance of not
>>> being able to access the system if something screwed up. Kind of like
>>> some company which suggested removing the passwords from the /etc/passwd
>>> file and putting them in a database. That scared the others in
>>> comp.unix.wizards at the time -- though now that is just what the unix
>>> under Mac's OS-X does.
>>
>> Well, the first shadow password suite was in comp.sources.misc volume 26
>> which was lat 1991 and the 3B line died in 1990 so it is pretty safe bet
>> that AT&T never officially adopted it.
>
> O.K. That does not mean that someone has not implemented it
> from those sources -- perhaps even in the machine which started this
> thread. :-)
While possible, based on my experience with who actually used 3B2's I
think it unlikely. While the machine (and CPU) had great promise they
were really pretty crippled, as delivered, unless you had lots of money.
And their lifetime was so short that even that didn't help by the time
most of them made it into the hands of people who would play with them.
Sad really.
>
> [ ... ]
>
>>>> OK, I'll see your Intergraph and raise you a Tektronix 4300 family
>>>> graphics station.
>>>
>>> Was that the one with a QIC tape drive in the right pedestal? I
>>> think that I have the tapes from one hiding somewhere around. :-)
>>
>> Nope. All the software it needed as a graphics design station was in
>> firmware. But you could boot it out of this with CPM-86 and that even
>> came with Fortran. Had a pair of 8" (big clunky Shugart's) disks.
>
> O.K. The SA8002 and SA8004 (two and four surfaces, resulting in
> 10 MB or 20MB? My first machine actually came with the drivers for that,
> but with a 20 MB drive you could not put the man pages on. :-)
>
>>>
>>> The Intergraph was a significantly larger and heavier beastie.
>>> I had to run it up two deck plank boards to get it into the bed of my
>>> pickup, and those boards were sagging about 6-8" below the centerline
>>> between the ends. :-) I kept expecting them to break. I would guess
>>> about 600 pounds. I've got machine tools which weigh a lot more, and
>>> I'm not sure what the weight of the 6' rack filled with a Sun 3/260 and
>>> three Fujitsu Eagles was. A lot, for sure. :-)
>>
>> I have a real truck now, but when I thin about what I moved using my
>> old Volvo 200 series station wagon.... Once made three trips to Jersey
>> and came home with the car completely jammed to the ceiling (even had
>> one on the pasengers seat) with RA80/RA81 disk drives.
>
> Was there any clearance between the frame bumpers and the
> axle? :-)
Don't know. But it was a good thing I made the trip in the daytime
cause if it were night the headlights would have been pointed so high
as to be useless. :-)
>
>>>> Ran not only thier custom stuff but also CPM-86.
>>>
>>> Ouch! I never knew what the CPU was in the beastie we had
>>> hanging around in the hall for a year or two after we moved into that
>>> building. It finally found an owner to turn it in during one of the
>>> regular property roundups -- someone got tired of having to travel to
>>> our building to verify that it was still there. :-)
>>
>> I have picked up a lot of gear that way. I got the Tek when we had a
>> visit from and auditor who wanted to know why we were paying to store
>> it. He said dump it and we did. Right into the back of that infamous
>> Volvo station wagon. :-) That also how I got all my Teraks.
>
> I couldn't get things that way. This was the government, and we
> were forced to do paperwork to turn it in so it could be sold for $5.00
> at a surplus sale. :-) The paperwork cost more than the income from
> it. :-)
A yes. Property Disposal. How I remember having to send stuff into
maintenance for repair/refurbishment so it could be turned in for
disposal. Of course the worst of this had to be the M151A1, the Jeep.
Had to be in perfect condition to be turned in so that PDO could cut
it up and sell it as scrap iron. (That was after the government decided
Army Jeeps were too dangerous to put on public roads and they stopped
selling them as functional vehicles.)
Yeah, missed them in the list. And, I am sure a couple others. Siemans
and Bull were already making Unix boxes by this point and may have also
used M68K's. Of course, IBM had an M68K box as well. Target was labs.
This was before the PC or their RISC systems.
> My 1/120 had a 10 MHz 68010 (same as the 3B1, but BSD
> flavor). I *think* that the original SUN had the 68000 plain vanilla,
> like my Coamos CMS-16/UNX.
Yep. I know of a number of M68K Sun's still running.
>
>> That's what the IBM PC was supposed to be, but that's another story.
>
> That would have been an interesting twist to history. I wonder
> where things would be if that had happened?
Well, for one thing, MS would likely have never got the stranglehold on
the industry they have.
Not on the CPU as far as I know. But I expect they probably had MRV11
modules with custom firmware embeded. Never had the chance to get my
hands on one to see what the actual config was. I would love to hear
what the compliment of modules in yours is. ;-) Do oyu actually use
it or is it a museum piece? If the former, I would be glad to try to
help you revive it.
Bill Gunshannon
Thad Floryan <th...@thadlabs.com> writes:
> On Jan 13, 6:56 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
>> [...]
>> Yeah, was passed out in comp.sources.misc. But we didn't call it
>> "Open Source" in those days. We just wrote code and gave it away.
>> Everyone knows Stallman invented Open Source.
>> [...]
>
> Oh? I would politely disagree. :-)
I guess you couldn't see my tongue planted firmly in my cheek. :-)
Surely you have heard the Stallmanites and Linux weenies sing the
praises of how if it weren't for the FSF and GPL there would be
no open source software.
>
> Back in the 1960s we had clearly the model of what is today's
> open source. The tapes would be in a cabinet, anyone was free
> to copy or use the tapes, make changes, write a new tape, and
> place that tape in the cabinet for others to use or learn from.
>
> Do a Google search on "UCB SDS-930" or "Project Genie" or visit:
>
> <http://en.wikipedia.org/wiki/Project_Genie>
Or just search for "comp.sources.*" :-)
>
> Genie was started and funded by ARPA, the same folks who begat
> ARPANET and, later, circa 1975, funded Stallman's EMACS project
> which was also open source.
>
> I have been using EMACS since 1976 or so and the oldest EMACS
> manual I could find in my files was handed to me by RMS in
> John McCarthy's office at Stanford early September 1980. A
> recent scan (2008) of that manual can be seen here:
>
> <http://thadlabs.com/FILES/Emacs-150_1980.09.05.pdf>
>
> 9.1 MB, 210 pages. I have a copy of the tape in my files
> but no way to read it.
Is it a 9-track? I can read that if you want to recover the contents
and put them onto something more modern.
Thad Floryan
> In article <6046cef4-dfae-49f4-9fd9-ae0b75c67...@l33g2000pri.googlegroups.com>,
> Thad Floryan <t...@thadlabs.com> writes:
>
> > [...]
> > 9.1 MB, 210 pages. I have a copy of the tape in my files
> > but no way to read it.
>
> Is it a 9-track? I can read that if you want to recover the contents
> and put them onto something more modern.
Good question. Fortunately I have a hardcopy printout of the tape's
contents (actually 4 tapes and 3 printouts; one tape's contents is
unknown). One tape has EMACS and other stuff from 1977, another
tape has the September 1980 EMACS.
Looking at the printout and the directory and filename syntax, it
appears to be a TOPS-20 DUMPER tape, so that means DECsystem-20 and
9-track with 100% confidence. My older PDP-10s had 7-track tapes.
Looks like I wrote the tape(s) at 1:38am Saturday Oct. 25, 1980,
and it looks like I should scan the tape directory printouts before
the paper disintegrates. :-)
Hmmm, I just did some checking and found a long-time friend who's
located in Fremont CA (just across SF Bay from me) who's heavily
into PDP-10 and DEC_20 systems (<http://www.inwap.com/>) and I
am going to email him asking if he can read these tapes.
If he's unable to do so, I'll get back to you; thanks for the
offer!
DoN. Nichols
> In article <slrngmqu2s....@katana.d-and-d.com>,
> "DoN. Nichols" <dnic...@d-and-d.com> writes:
>> On 2009-01-13, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>>> In article <slrngmo6kh....@katana.d-and-d.com>,
[ ... ]
>>> Pure MFM. SCSI came much later as an add on card. Doesn't mean people
>>> didn't then put MFM on the SCSI controller but it sure wouldn't make
>>> much sense to do so. Biggest MFM disk was ~70 meg.
>>
>> Actually, the biggest MFM 5.25" full height drive was the Maxtor
>> and Priam 190 MB (raw), which formatted to 160 MB on the 3B1.
>
> Never saw one that big, but the limit I was thinking of was probably on
> the controller and not the actual disk now that I think about it.
O.K. 67 MB full height was the largest that the 3B1 could
handle without modification. You could get a half-height Miniscribe
which would handle the same space, but had too many cylinders for the
WD1010 hard disk controller chip. Replace it with a WD2010 and you have
the ability to run the Miniscribe, so you could get 67 MB in a 7300
(half height drive bay) instead of requiring the 3B1 (full-height drive
bay).
To get more than that, you had to do some hardware modification
on the system board. For a single drive, you needed a little extra
circuitry to latch a fourth head-select line. While you were there, it
was easy to also add a little more circuitry to allow a second
drive-select line as well. So -- I had one 3B1 running one Priam 190 MB
drive (160 MB formatted for the 3B1) and one half-height Miniscribe at
67 MB formatted -- both in a 3B2 external disk box, along with the
floppy tape drive. A little trickery to supply the 5V to turn on the
power supply in the drive box (5V from the original power connector for
the internal hard disk drive). I never did come across another 190 MB
drive -- either Priam or Maxtor -- during the time I was still using the
systems regularly -- but someone else from this newsgroup brought a pair
of drives around which would no longer boot the system, and needed data
extracted from them, so I set my 3B1 up to run from the single Priam 190
and copied data into it a filesystem tree at a time, then copied to one
of my Suns where I could collect it all and burn a CD-ROM for him.
Then, he left, taking the two Maxtor 190s with him. :-(
> Wasn't
> the 3B1 limited to 70M?
As supplied -- yes. about that. no more than eight surfaces,
and no more than 1024 tracks. Change the controller chip and you get
more tracks, a bit of wiring (mostly stealing spare chip sections, and
adding two chips in spare holes) and you get the possibility of two 190
MB (raw) drives, or two 160 MB formatted for the 3B1. (The 3B1 was very
generous in allocating spare sectors all over the place -- and for good
reason. :-)
I got WD2010 controller chips by looking for old PC hard drive
cards in boxes at hamfests. I would dig through them, and select those
which used socketed WD2010 chips -- and one which had it directly
soldered so I had to spend a lot of time with a solder sucker. :-)
> I know the Tandy was. I once built a system that
> had 4 70M drives, all the memory you could cram in and 6 additional serial
> ports. That was considered a killer machine. The serial ports were hooked
> up to Sytek Netmork Ports (Broadband Network!) and we ran UNaXcess BBS on
> it. Even had a gateway to real USENET. Work is never like that anymore.
UNaXcess! I ran that for a while on the first Tekronix 6130.
(I also compiled and ran ISPICE on it, since it was written for a BSD
system, and was a *real* pain to port to a SysV system such as the
UniSys 680x0 which I had to use at work.
>>> Not much space,
>>> even in those days. I saw a 3B2 running as a USENET News Server. Not
>>> going to do that long with only 2 70meg disks when the OS easily takes
>>> up one whole disk. :-)
>>
>> Well ... you could strip out a lot of the OS if it were only to
>> be a news server.
>
> Actually, with the 3B2 (actually with anything out of AT&T) you don't
> strip it to get work done, you add all the stuff they made optional.
> Like a compiler!!
Right. Of course, after you had compiled the cnews package and
had it working properly, you could then strip out the development
system. (And by then, I had jove working in the 3B1, so I could do
without "vi" which came with the development system. Of course, I had
the 190 MB Prim in service, and only carried a few newgroups
(including comp.sys.3b1 (or unixpc.* before they passed the newgroup
vote.)
>> You would need to keep uucp (unless you were running
>> NNTP instead),
>
> At that time there was no NNTP all of USENET was still UUCP.
At least I was using uucp go get mine -- from uunet before they
changed the modems used from Telebit TrailBlazers to something which was
nominally faster, but in reality a lot slower for uucp connections than
the TrailBlazers with uucp spoofing turned on. At that point, I could
no longer afford to keep uunet and transferred to digex with a SLIP
feed. They later moved me to Frame Relay, then changed owners and name
twice, and somewhere along dropped support for Frame Relay, so I moved to
T1, which I am still using -- on yet a different ISP.
> UUCP: {philabs}\
> {phri } >!trotter.usma.edu!bill
> {sunybcs}/
Ah yes -- the bang paths!
> Remember the group mail.maps?
Yep! One of the advantages of using uunet was that I could use
a FQDN to both send and receive e-mail, though the first hop was uucp.
So I did try to bring up the maps package, but it cost too much
bandwidth to keep it updated, so I just used the domain names. IIRC, it
looked something like this:
ceilidh!uunet!username@FQDN
> And, the 3B2 had no TCPIP. Eventually
> Woolongong did one but AT&T never did that I was aware of. That was
> a Berkeley thing, not SYS V.
The 3B1 used the WillGoWrong TCP/IP package -- with certain
problems:
1) There was *no* ping -- because the kernel lacked the microtime
function needed for that to work.
2) A "ping -f" from a Sun 2/120 was enough to crash the system.
>> and you would need to keep at least one editor, but a lot
>> of the application programs (including the Documenter's Workbench) could
>> be stripped out. And blowing away the Man pages would make a lot of
>> room.
>
> Tough to do when your news server is also a general purpose machine.
> USENET (especially News) was a lot samller in those days. We didn't
> even have a USENET 500. :-)
Yep! I was mostly only carrying comp.sys.3b1, comp.sources.3b1,
alt.folklore.computers, alt.folklore.urban, comp.unix.wizards, and a few
others -- but not much at uunet's connect time charges. :-)
>> The 3B1 never had on-line manuals. Add to that the fact that the
>> default editor if you clicked on a file was "ed", and the only
>> documentation for ed was in the development set, which also got you vi
>> so you would not use ed by choice at all. :-) Of course, the assumption
>> was that Mr. Businessman, who had it on his desk,
>
> I doubt any businessman ever had a 3B2 "on his desk".
Nope -- not the 3B2 -- the 3B1. That is why it connected
between the phone line and the phone, and would dial calls for you --
and keep a record of how long your calls were to which numbers.
And the GUI was *supposed* to make it easier for Mr.
Businessman, at lest until it dumped him into "ed" on working on a file
he clicked on, with no documentation on how to get out of it.
It *did* make it easier to break into a system which you had
lost the password for. Log in as guest (by default no password), send
yourself some e-mail, then click on the mail icon when it popped up, and
bang out of the mail program to a root shell. :-)
> He might have used
> it for a desk, but "on his desk" would have left no room for even his
> phone. :-) Actually, I imagine most of them resided in computer rooms.
> They were big, noisy, generated heat and certainly offered no kind of
> built in terminal capability anyway. But we had termcap so just about any
> terminal in the world worked. I kinda miss my TeleVideo-950.
While the 3B1 was a pretty nice terminal for the time.
>> would have installed a
>> word processing package which would replace the ed as the default
>> editor. I can just imagine a businessman trying to find out how to get
>> out of a program which simply prompts with a '?'. :-) I had other
>> manuals from other versions when I got my first 7300, so I had a chance
>> to deal with that.
>
> Actually, I can't imagine a businessman using a 3B2 at all. :-) But then,
> that wasn't the target market.
But he *was* the target for the 3B1. Pretty raked styling, with
the floppy drive hiding behind the keyboard.
[ ... ]
>>>> I actually used my first MFM drives (a pair of Ampex 27 MB
>>>> drives) using a MFM<-->SCSI adaptor and a hand wire-wrapped host adaptor
>>>
>>> I thought you had been doing this a lot longer than that.
>>
>> I was. I started with a pair of 5.6 MB drives by IMI (IIRC),
Actually -- I *started* with the Altair 680b at home, and managed
to hook it up to a digital cassette drive bearing Ampex's name, but
which they did not remember that they had ever made when I called to get
parts. (The pinch rollers started turning to black goo and making a
mess of the tapes.)
[ ... ]
>>> Of course, Microware is all
>>> the way up to OS-9000 now. :-) I still have systems running OS9. I
>>> just wish they would open source OS9 and OS9-68K, but I doubt it will
>>> ever happen.
>>
>> That would be nice. It would give me something to run on a set
>> of VME cards which include a 68K CPU (68020 IIRC) and a floppy
>> interface. Until I get an OS, I won't bother hanging power supplies on
>> the card cage. :-)
>
> Yeah, I have a couple of QBUS M68K cards that would make great OS9-68K
> machines. And, it's ROMable!!
I actually have such as set of Qbus cards too.
And with the 68K's address space, you could put the whole OS
including device drivers and device descriptors in ROM (except for
something which you were developing) and have plenty of address space
left for your applications.
Even on a SWTP 6809, with 56 K of RAM, and a lot of OS-9 in 4K
of EPROM there was enough room so my wife and I could use it as the same
time, as long as I avoided running a big Pascal compile, or used the
work processor (Stylo, IIRC.)
[ ... ]
>>>> Those systems shared four 8" floppys and four 5.26" floppies as
>>>> well.
>>>
>>> OS/9 always did a good job of disk handling. Could easily handle many drives
>>> all in different formats. A really good OS.
>>
>> Right. I even wrote a modified floppy driver for it to handle
>> the Radio Shack Color Computer OS-9 format -- which had to skip over the
>> Radio Shack directory which was always in the middle tracks. :-) I did
>> this so I could use the more affordable C compiler from them instead of
>> paying Microware the extra bucks for normal floppys. (I also had to do a
>> little tweaking to the binaries to keep it from forcing the source to
>> live on a different disk than the compiler did. :-)
>
> I still have Tandy Color Computers. The only thing I ever ran onthem was
> OS-9. :-)
:-) I gave mine to a friend whose daughter needed to learn
computers. (She did quite well at it. :-)
[ ... ]
>>> Yeah, was passed out in comp.sources.misc.
>>
>> Yep. When it came out, I was using (remotely) a BBN C70
>> which was the e-mail system for the area where I worked. 10-bit bytes,
>> 20-bit words, 40-bit longs. :-) And some of them had no unsigned (or was
>> it no signed) version. :-)
>>
>> It really blew the normal "compress" program out of the water,
>
> Didn't take much. There were many machines that couldnot do the higher
> compression ratios so you frequently found yourself unable to uncompress
> something you got from USENET.
The first Tektronix 6130 was where I first hit that. I had
compiled it with no problem, then started to compress various things and
the system came to a screeching halt. It had all of 1MB of RAM (until I
got some extra cards from another system) and used about 400K for the
OS, so when compress wanted to build it's 1MB sized table it kept
checking for fit deeper and deeper into the table, forcing parts of the
table to page out to swap and be replaced by another part, and then
looped around for the next byte to repeat the check pass. I had made
the mistake of backgrounding it, and the system was thrashing so badly
that it took over five minutes to get logged in on another serial port,
and then a lot longer to use "ps -axl" to get the PID so I could kill
it.
After that, I re-compiled it so it used smaller tables and was
able to use it for compression safely enough.
I never actually tried uncompressing something from another
system on it to see whether it could handle that. :-)
[ ... ]
>>> Well, the first shadow password suite was in comp.sources.misc volume 26
>>> which was lat 1991 and the 3B line died in 1990 so it is pretty safe bet
>>> that AT&T never officially adopted it.
>>
>> O.K. That does not mean that someone has not implemented it
>> from those sources -- perhaps even in the machine which started this
>> thread. :-)
>
> While possible, based on my experience with who actually used 3B2's I
> think it unlikely. While the machine (and CPU) had great promise they
> were really pretty crippled, as delivered, unless you had lots of money.
> And their lifetime was so short that even that didn't help by the time
> most of them made it into the hands of people who would play with them.
> Sad really.
The 3B1 became a true hacker's machine. I've only heard of a
few 3B2 machines in hobby hands.
[ ... ]
>>> I have a real truck now, but when I thin about what I moved using my
>>> old Volvo 200 series station wagon.... Once made three trips to Jersey
>>> and came home with the car completely jammed to the ceiling (even had
>>> one on the pasengers seat) with RA80/RA81 disk drives.
>>
>> Was there any clearance between the frame bumpers and the
>> axle? :-)
>
> Don't know. But it was a good thing I made the trip in the daytime
> cause if it were night the headlights would have been pointed so high
> as to be useless. :-)
:-)
Try what one friend encountered when bringing a big military
surplus transmitter home in the trunk of a car. He and his friend could
*barely* lift it -- but the car kept following it up, so getting it clear
of the trunk was a major problem. :-)
[ ... ]
>> I couldn't get things that way. This was the government, and we
>> were forced to do paperwork to turn it in so it could be sold for $5.00
>> at a surplus sale. :-) The paperwork cost more than the income from
>> it. :-)
>
> A yes. Property Disposal. How I remember having to send stuff into
> maintenance for repair/refurbishment so it could be turned in for
> disposal. Of course the worst of this had to be the M151A1, the Jeep.
> Had to be in perfect condition to be turned in so that PDO could cut
> it up and sell it as scrap iron. (That was after the government decided
> Army Jeeps were too dangerous to put on public roads and they stopped
> selling them as functional vehicles.)
That sounds like normal Army procedure.
Sometimes, the only way we *could* turn in some test equipment
was to send it off for calibration, and when it came back with a red tag
"Not economical to repair", we could turn it in. I remember all three
of our Tripplett 601 FET-VOMs hit that in one cycle. (The problem was
that the manual wanted four AA Mercury cells in a part of the battery
clips to act as references, and the rest could be Zinc Carbon or
Alkaline. It would work prefectly well with all Zinc Carbon or
Alkaline, but they discovered that Mercury cells were suddenly made of
UnObtanium, and so took all three out of service. I still have one
which I use form time to time -- especially when a moving needle is nice
to have.
[ ... ]
>>> Well, NCR already had a line of computers and when AT&T acquired them they
>>> became the AT&T Computer Division so it was obvious which way they would
>>> go. That, and at that time the small unix system market was pretty much
>>> M68K based. Unisys, Prime, NCR, Convergent, Tandy, all the real players.
>>
>> Was Sun in business by then? They started with the 68K
>> processors.
>
> Yeah, missed them in the list. And, I am sure a couple others. Siemans
> and Bull were already making Unix boxes by this point and may have also
> used M68K's. Of course, IBM had an M68K box as well. Target was labs.
> This was before the PC or their RISC systems.
Wasn't Apollo in the 68K game too?
>> My 1/120 had a 10 MHz 68010 (same as the 3B1, but BSD
>> flavor). I *think* that the original SUN had the 68000 plain vanilla,
>> like my Coamos CMS-16/UNX.
>
> Yep. I know of a number of M68K Sun's still running.
I've got quite a few which *could* run, but the power versus
computron ratio says that I run the UltraSPARCs for most things. :-)
>>> That's what the IBM PC was supposed to be, but that's another story.
>>
>> That would have been an interesting twist to history. I wonder
>> where things would be if that had happened?
>
> Well, for one thing, MS would likely have never got the stranglehold on
> the industry they have.
Exactly. They didn't know where to steal an OS for the 68K. :-)
Now, if the PC had started with the 6809 and OS-9 it would have
been a *much* more attractive machine to me. :-)
[ ... ]
>>>> I also have a Bridgeport BOSS-3 CNC mill with a serious case of
>>>> electronics Altzheimer's built on a quad-wide LSI-11. That is coming
>>>> out, and being replaced with a linux-based EMC package.
>>>
>>> Not surprised. I once sent a couple of 11/02 modules to a guy out west
>>> to fix his Bridgeport. I'll bet there are a bunch of them running in
>>> all the speed shops we have around here.
>>
>> As far as I can tell, they had custom firmware on the chips as
>> well.
>
> Not on the CPU as far as I know. But I expect they probably had MRV11
> modules with custom firmware embeded. Never had the chance to get my
> hands on one to see what the actual config was. I would love to hear
> what the compliment of modules in yours is. ;-) Do oyu actually use
> it or is it a museum piece? If the former, I would be glad to try to
> help you revive it.
It had a bad case of Electronic Altzheimer's. Reset it, and
within fifteen seconds it would forget what it was doing -- unless it
was so hot that I was rusting everything in sight with sweat.
I got a newer version (same CPU, different layout of driver
hardware, and the other three (custom) cards were real PCs instead of
wire-wrapped boards as was in the first.
I got about half-way through splicing it back together when I
started running into wires which did not match at the other end (they
had simply cut a bundle of wires about 1-1/2" in diameter running form
the electronics/computer box to the power box and other controls. The
thing had a giant three-phase transformer feeding AC to three power
supplies which include saturable reactors (mag-amps) to control the
voltage fed to the three stepper motor drivers -- lower voltage (about
50 VDC) when holding position or stepping slowly, higher voltage (about
80 VDC) when stepping rapidly to overcome the inductance in the
steppers. Even so, the maximum "rapid" motion wasn't very.
As a result, I'm pulling out the electronics and the drivers,
replacing the stepper motors with DC servos and matching DC servo amps,
and building EMC (Extensible Machine Control) from NIST into a
rack-mount Pentium box running linux.
But -- right now I need to fabricate and have welded up a
replacement Y-axis drive belt housing -- to move the longer servo motors
over to the right of the mill's knee, since it is too long for the space
allocated to the original steppers.
If you are interested, I could pull out the quad LSI-11 card and
list the chips present -- especially if you could point me to any other
than the four 40-pin ones which might be important.
The card cage is weird. One slot for the LSI-11/02 with the
standard DEC connectors, and the rest are a totally different bus, unique
to the Bridgeport box. :-)
Enjoy,
Bill Gunshannon
"DoN. Nichols" <dnic...@d-and-d.com> writes:
> On 2009-01-14, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>> In article <slrngmqu2s....@katana.d-and-d.com>,
>> "DoN. Nichols" <dnic...@d-and-d.com> writes:
>>> On 2009-01-13, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>>>> In article <slrngmo6kh....@katana.d-and-d.com>,
>
> [ ... ]
>
> handle without modification. You could get a half-height Miniscribe
> which would handle the same space, but had too many cylinders for the
> WD1010 hard disk controller chip. Replace it with a WD2010 and you have
> the ability to run the Miniscribe, so you could get 67 MB in a 7300
> (half height drive bay) instead of requiring the 3B1 (full-height drive
> bay).
I remember reading about this mod. But all my 3B1/UnixPC's (whichever one
didn't have the hump) are still pristine. And they all work, too.
>
> [ ... ]
>
>>> You would need to keep uucp (unless you were running
>>> NNTP instead),
>>
>> At that time there was no NNTP all of USENET was still UUCP.
>
> At least I was using uucp go get mine -- from uunet before they
> changed the modems used from Telebit TrailBlazers to something which was
I still have a pair of TrailBlazers in my collection.
> nominally faster, but in reality a lot slower for uucp connections than
> the TrailBlazers with uucp spoofing turned on. At that point, I could
> no longer afford to keep uunet and transferred to digex with a SLIP
> feed. They later moved me to Frame Relay, then changed owners and name
> twice, and somewhere along dropped support for Frame Relay, so I moved to
> T1, which I am still using -- on yet a different ISP.
>
>> UUCP: {philabs}\
>> {phri } >!trotter.usma.edu!bill
>> {sunybcs}/
>
> Ah yes -- the bang paths!
>
>> Remember the group mail.maps?
>
> Yep! One of the advantages of using uunet was that I could use
> a FQDN to both send and receive e-mail, though the first hop was uucp.
> So I did try to bring up the maps package, but it cost too much
> bandwidth to keep it updated, so I just used the domain names. IIRC, it
> looked something like this:
>
> ceilidh!uunet!username@FQDN
>
I keep trying to convince people that we really need to revive this email
system. It offers the best and quickest solution to the SPAM problem but
apparently I am the only one who can see that.
>> And, the 3B2 had no TCPIP. Eventually
>> Woolongong did one but AT&T never did that I was aware of. That was
>> a Berkeley thing, not SYS V.
>
> The 3B1 used the WillGoWrong TCP/IP package -- with certain
> problems:
>
> 1) There was *no* ping -- because the kernel lacked the microtime
> function needed for that to work.
>
> 2) A "ping -f" from a Sun 2/120 was enough to crash the system.
>
Do you remember when it was also the TCPIP package on VMS? Of course,
I think they were also the ones who gave us "Eunice". :-)
>>> and you would need to keep at least one editor, but a lot
>>> of the application programs (including the Documenter's Workbench) could
>>> be stripped out. And blowing away the Man pages would make a lot of
>>> room.
>>
>> Tough to do when your news server is also a general purpose machine.
>> USENET (especially News) was a lot samller in those days. We didn't
>> even have a USENET 500. :-)
>
> Yep! I was mostly only carrying comp.sys.3b1, comp.sources.3b1,
> alt.folklore.computers, alt.folklore.urban, comp.unix.wizards, and a few
> others -- but not much at uunet's connect time charges. :-)
>
Remember where UUNET came from? I tried to sell the Tech Center people
here on the practicality of a business offering Email and News using
UUNET as my business case. This was before the first ISP or even the
INTERNET (outside of the University where I had been hired to set it up)
existed in NEPA. They could not see where anyone would be willing to
pay money for something like Email or News. :-(
>>> The 3B1 never had on-line manuals. Add to that the fact that the
>>> default editor if you clicked on a file was "ed", and the only
>>> documentation for ed was in the development set, which also got you vi
>>> so you would not use ed by choice at all. :-) Of course, the assumption
>>> was that Mr. Businessman, who had it on his desk,
>>
>> I doubt any businessman ever had a 3B2 "on his desk".
>
> Nope -- not the 3B2 -- the 3B1. That is why it connected
> between the phone line and the phone, and would dial calls for you --
> and keep a record of how long your calls were to which numbers.
>
> And the GUI was *supposed* to make it easier for Mr.
> Businessman, at lest until it dumped him into "ed" on working on a file
> he clicked on, with no documentation on how to get out of it.
Actually, I thought most of the desktop 3B1's had word processing software
on them. Wasn't there a very popular third party package for that?
>
> It *did* make it easier to break into a system which you had
> lost the password for. Log in as guest (by default no password), send
> yourself some e-mail, then click on the mail icon when it popped up, and
> bang out of the mail program to a root shell. :-)
Yeah, I remember that. Kind of like iPhones that all over the world have
the same root password. ;-)
>
>> He might have used
>> it for a desk, but "on his desk" would have left no room for even his
>> phone. :-) Actually, I imagine most of them resided in computer rooms.
>> They were big, noisy, generated heat and certainly offered no kind of
>> built in terminal capability anyway. But we had termcap so just about any
>> terminal in the world worked. I kinda miss my TeleVideo-950.
>
> While the 3B1 was a pretty nice terminal for the time.
>
>>> would have installed a
>>> word processing package which would replace the ed as the default
>>> editor. I can just imagine a businessman trying to find out how to get
>>> out of a program which simply prompts with a '?'. :-) I had other
>>> manuals from other versions when I got my first 7300, so I had a chance
>>> to deal with that.
>>
>> Actually, I can't imagine a businessman using a 3B2 at all. :-) But then,
>> that wasn't the target market.
>
> But he *was* the target for the 3B1. Pretty raked styling, with
> the floppy drive hiding behind the keyboard.
And still they couldn't make a sucess of them.
>
> [ ... ]
>
>>>>> I actually used my first MFM drives (a pair of Ampex 27 MB
>>>>> drives) using a MFM<-->SCSI adaptor and a hand wire-wrapped host adaptor
>>>>
>>>> I thought you had been doing this a lot longer than that.
>>>
>>> I was. I started with a pair of 5.6 MB drives by IMI (IIRC),
>
> Actually -- I *started* with the Altair 680b at home, and managed
> to hook it up to a digital cassette drive bearing Ampex's name, but
> which they did not remember that they had ever made when I called to get
> parts. (The pinch rollers started turning to black goo and making a
> mess of the tapes.)
>
> [ ... ]
>
>>>> Of course, Microware is all
>>>> the way up to OS-9000 now. :-) I still have systems running OS9. I
>>>> just wish they would open source OS9 and OS9-68K, but I doubt it will
>>>> ever happen.
>>>
>>> That would be nice. It would give me something to run on a set
>>> of VME cards which include a 68K CPU (68020 IIRC) and a floppy
>>> interface. Until I get an OS, I won't bother hanging power supplies on
>>> the card cage. :-)
>>
>> Yeah, I have a couple of QBUS M68K cards that would make great OS9-68K
>> machines. And, it's ROMable!!
>
> I actually have such as set of Qbus cards too.
Integrated Solutions? If so, which PROMs? They had two. One booted a
version of Unix (which I have not been able to find) and the other was
MIKBUG (I think). Mine have the Unix boot PROMs. :-(
>
> And with the 68K's address space, you could put the whole OS
> including device drivers and device descriptors in ROM (except for
> something which you were developing) and have plenty of address space
> left for your applications.
>
> Even on a SWTP 6809, with 56 K of RAM, and a lot of OS-9 in 4K
> of EPROM there was enough room so my wife and I could use it as the same
> time, as long as I avoided running a big Pascal compile, or used the
> work processor (Stylo, IIRC.)
OS-9 was rather amazing that way. Imagine the looks on people's faces
when I demoed three people logged into a Tandy Color Computer with 1 floppy
and two serial ports (one bit banger and one UART based) and, of course,
the console. And, I hears it was possible to modify the RS232 PAK so
that with a MultiPAK interface you could even have two more serial
ports and support users on all of them. All with a 6809 and 64K of
memory.
>
> [ ... ]
>
>>>> Well, the first shadow password suite was in comp.sources.misc volume 26
>>>> which was lat 1991 and the 3B line died in 1990 so it is pretty safe bet
>>>> that AT&T never officially adopted it.
>>>
>>> O.K. That does not mean that someone has not implemented it
>>> from those sources -- perhaps even in the machine which started this
>>> thread. :-)
>>
>> While possible, based on my experience with who actually used 3B2's I
>> think it unlikely. While the machine (and CPU) had great promise they
>> were really pretty crippled, as delivered, unless you had lots of money.
>> And their lifetime was so short that even that didn't help by the time
>> most of them made it into the hands of people who would play with them.
>> Sad really.
>
> The 3B1 became a true hacker's machine. I've only heard of a
> few 3B2 machines in hobby hands.
Probably because without a supply of spare parts they ended out in the
dumpster like both of mine. NCR did a good job of destroying everything
as they did their "upgrades".
>
> [ ... ]
>
>>>> I have a real truck now, but when I thin about what I moved using my
>>>> old Volvo 200 series station wagon.... Once made three trips to Jersey
>>>> and came home with the car completely jammed to the ceiling (even had
>>>> one on the pasengers seat) with RA80/RA81 disk drives.
>>>
>>> Was there any clearance between the frame bumpers and the
>>> axle? :-)
>>
>> Don't know. But it was a good thing I made the trip in the daytime
>> cause if it were night the headlights would have been pointed so high
>> as to be useless. :-)
>
> :-)
>
> Try what one friend encountered when bringing a big military
> surplus transmitter home in the trunk of a car. He and his friend could
> *barely* lift it -- but the car kept following it up, so getting it clear
> of the trunk was a major problem. :-)
T-368? :-)
>
> [ ... ]
>
>>>> Well, NCR already had a line of computers and when AT&T acquired them they
>>>> became the AT&T Computer Division so it was obvious which way they would
>>>> go. That, and at that time the small unix system market was pretty much
>>>> M68K based. Unisys, Prime, NCR, Convergent, Tandy, all the real players.
>>>
>>> Was Sun in business by then? They started with the 68K
>>> processors.
>>
>> Yeah, missed them in the list. And, I am sure a couple others. Siemans
>> and Bull were already making Unix boxes by this point and may have also
>> used M68K's. Of course, IBM had an M68K box as well. Target was labs.
>> This was before the PC or their RISC systems.
>
> Wasn't Apollo in the 68K game too?
Yeah, forgot them on my list as well. And I even had one of them.
>
>>> My 1/120 had a 10 MHz 68010 (same as the 3B1, but BSD
>>> flavor). I *think* that the original SUN had the 68000 plain vanilla,
>>> like my Coamos CMS-16/UNX.
>>
>> Yep. I know of a number of M68K Sun's still running.
>
> I've got quite a few which *could* run, but the power versus
> computron ratio says that I run the UltraSPARCs for most things. :-)
Speaking of SUN 3's..... Know anybody who might be interested in a pair
of Deskside pedestal model 3's? I just checked and the Physics department
still has their but need to get rid of them real soon now before the move
to the new Science Building.
>
>>>> That's what the IBM PC was supposed to be, but that's another story.
>>>
>>> That would have been an interesting twist to history. I wonder
>>> where things would be if that had happened?
>>
>> Well, for one thing, MS would likely have never got the stranglehold on
>> the industry they have.
>
> Exactly. They didn't know where to steal an OS for the 68K. :-)
Actually, they already had M68K based desktop systems. Ran Unix.
>
> Now, if the PC had started with the 6809 and OS-9 it would have
> been a *much* more attractive machine to me. :-)
6809 was already deadend technology by that point.
>
> [ ... ]
>
>
> If you are interested, I could pull out the quad LSI-11 card and
> list the chips present -- especially if you could point me to any other
> than the four 40-pin ones which might be important.
I sent a dual-wide LSI-11/02 to a guy out west and as far as I know it made
his work. I never saw a quad-wide 11/02. 11/03, yes, but not an 11/02.
>
> The card cage is weird. One slot for the LSI-11/02 with the
> standard DEC connectors, and the rest are a totally different bus, unique
> to the Bridgeport box. :-)
Didn't know that. I was always led to believe that the Bridgeport had a
complete, real PDP-11 in it with custom QBUS boards to interface to the
real machine. I have never actually seen one.
Aharon Robbins
Thad Floryan <th...@thadlabs.com> wrote:
>I have been using EMACS since 1976 or so and the oldest EMACS
>manual I could find in my files was handed to me by RMS in
>John McCarthy's office at Stanford early September 1980. A
>recent scan (2008) of that manual can be seen here:
>
><http://thadlabs.com/FILES/Emacs-150_1980.09.05.pdf>
>
>9.1 MB, 210 pages. I have a copy of the tape in my files
>but no way to read it.
All of the talk about old computers is pretty amazing.
See www.bitsavers.org for some possible help in finding something to
read an old tape.
See www.tuhs.org (The Unix Historical Society) for source code for
various old Unixes.
The 3B1 was my first personal computer and Unix machine, circa 1987;
for a while I was a member of the 3b1.* alternate USENET network
amongst a few other 3B1 users in the US. It was lots of fun. I was
skeeve!arnold in those days; then later arn...@skeeve.atl.ga.us.
I still have very fond memories of that machine.
My main system is still called skeeve; it has just gone through it's
fourth regeneration to a different architecture (MC68010 -> Sun SPARC ->
Intel x86 -> x86_64). The difference in capabilities vs. cost from then
to now is amazing...
Arnold
--
Aharon (Arnold) Robbins arnold AT skeeve DOT com
P.O. Box 354 Home Phone: +972 8 979-0381
Nof Ayalon Cell Phone: +972 50 729-7545
D.N. Shimshon 99785 ISRAEL
Thad Floryan
> [...]
> All of the talk about old computers is pretty amazing.
Heh, it is. :-)
But unless one has plenty of free time, "playing" with
them is an extravagance. Still, I booted up one of my 3B1
systems recently to retrieve some old files and it took
a l-o-n-g time to boot.
I still have all the StarLAN stuff, too, including the
StarLAN:RS-232 boxes and a ton of software and manuals.
I'm going to have to get rid of the stuff soon, though,
as I'm totally out of room. Here's my desk about two
months ago: <http://thadlabs.com/PIX/Thad_desk.jpg>.
There's 18 computers visible in that photo. My 3B1s and
a bunch of Suns are in my garage and another room along
with my Amigas, a massive C64, and a Convergent Mitiframe.
> Seewww.bitsavers.orgfor some possible help in finding something to
> read an old tape.
>
> Seewww.tuhs.org(The Unix Historical Society) for source code for
> various old Unixes.
Thanks for those URL references!
> [...]
> My main system is still called skeeve; it has just gone through it's
> fourth regeneration to a different architecture (MC68010 -> Sun SPARC ->
> Intel x86 -> x86_64). The difference in capabilities vs. cost from then
> to now is amazing...
Ain't that the truth! Almost everything in the above picture
w-a-y outperforms a Cray-1 and I paid less than US$300 each new
for them (mostly Intel Core Duo and AMD x64) with another one
arriving Monday. Most of them double or triple boot (since I
only have a 16 port KVM for the PC hardware and a Lightwave KVM
for the Sun boxes all feeding the one NEC LCD seen in the photo).
Argh, when I think of what I paid for my 3B1 systems new or,
worse, for my first Sun-3/60 new. One of my $300 systems triple
boots into Vista, Fedora 10 and Solaris 10; you can see its
configuration from a Solaris point of view here:
<http://thadlabs.com/FILES/sysconfig.txt>
Computers are truly a commodity item today. :-)
DoN. Nichols
> In article <slrngmtmo2....@katana.d-and-d.com>,
> "DoN. Nichols" <dnic...@d-and-d.com> writes:
[ ... ]
>> O.K. 67 MB full height was the largest that the 3B1 could
>> handle without modification. You could get a half-height Miniscribe
>> which would handle the same space, but had too many cylinders for the
>> WD1010 hard disk controller chip. Replace it with a WD2010 and you have
>> the ability to run the Miniscribe, so you could get 67 MB in a 7300
>> (half height drive bay) instead of requiring the 3B1 (full-height drive
>> bay).
>
> I remember reading about this mod. But all my 3B1/UnixPC's (whichever one
> didn't have the hump) are still pristine. And they all work, too.
The 7300 didn't have the hump, the 3B1 did. UnixPC applied to
both AFIK. (And prompted questions to unixpc.general before
comp.sys.3b1 came into being of the form:
"How can I run unix on my PC?"
This was one of the reasons that unixpc was not in the final comp.sys
newsgroup. :-)
[ ... ]
>>> At that time there was no NNTP all of USENET was still UUCP.
>>
>> At least I was using uucp go get mine -- from uunet before they
>> changed the modems used from Telebit TrailBlazers to something which was
>
> I still have a pair of TrailBlazers in my collection.
As do I. (Actually, I think that one is a WorldBlazer.
[ ... ]
>> Ah yes -- the bang paths!
>>
>>> Remember the group mail.maps?
>>
>> Yep! One of the advantages of using uunet was that I could use
>> a FQDN to both send and receive e-mail, though the first hop was uucp.
>> So I did try to bring up the maps package, but it cost too much
>> bandwidth to keep it updated, so I just used the domain names. IIRC, it
>> looked something like this:
>>
>> ceilidh!uunet!username@FQDN
>>
>
> I keep trying to convince people that we really need to revive this email
> system. It offers the best and quickest solution to the SPAM problem but
> apparently I am the only one who can see that.
You know -- I think that would work! (Of course, it would bring
most uses of email to its knees given today's user base. :-)
>>> And, the 3B2 had no TCPIP. Eventually
>>> Woolongong did one but AT&T never did that I was aware of. That was
>>> a Berkeley thing, not SYS V.
>>
>> The 3B1 used the WillGoWrong TCP/IP package -- with certain
>> problems:
>>
>> 1) There was *no* ping -- because the kernel lacked the microtime
>> function needed for that to work.
>>
>> 2) A "ping -f" from a Sun 2/120 was enough to crash the system.
>>
>
> Do you remember when it was also the TCPIP package on VMS?
I never ran VMS -- or even accessed a machine running it. I've
got a friend who has been collecting VAXen in all sizes, and does run
VMS at home on one or two of the smaller ones. Not enough power to spin
up the larger ones, let alone not enough room. :-)
> Of course,
> I think they were also the ones who gave us "Eunice". :-)
Oh yes -- the only experience with "Eunice" that I have is the
comment from Larry Wall's "configure" script "Oh good! You're not
running Eunice." which told me that it must be pretty bad. :-)
[ ... ]
>> Yep! I was mostly only carrying comp.sys.3b1, comp.sources.3b1,
>> alt.folklore.computers, alt.folklore.urban, comp.unix.wizards, and a few
>> others -- but not much at uunet's connect time charges. :-)
>>
>
> Remember where UUNET came from?
I really never knew -- though I did know that they were local,
and even once visited them (before they moved) to pick up an Exabyte
tape of the sources tree.
UUNET seems to be dead, but ftp.uu.net still is out there -- it
just hasn't been updated in years.
I use it as the general target for ping or traceroute when I
have doubts about how my net connection is doing. :-)
> I tried to sell the Tech Center people
> here on the practicality of a business offering Email and News using
> UUNET as my business case. This was before the first ISP or even the
> INTERNET (outside of the University where I had been hired to set it up)
> existed in NEPA. They could not see where anyone would be willing to
> pay money for something like Email or News. :-(
Interesting. *I* certainly was willing to do so -- even while
working for an Army lab and getting access to Arpanet at the time.
[ ... ]
>>> I doubt any businessman ever had a 3B2 "on his desk".
>>
>> Nope -- not the 3B2 -- the 3B1. That is why it connected
>> between the phone line and the phone, and would dial calls for you --
>> and keep a record of how long your calls were to which numbers.
>>
>> And the GUI was *supposed* to make it easier for Mr.
>> Businessman, at lest until it dumped him into "ed" on working on a file
>> he clicked on, with no documentation on how to get out of it.
>
> Actually, I thought most of the desktop 3B1's had word processing software
> on them. Wasn't there a very popular third party package for that?
Let me see ... "Wordmark Composer"? That was on one of the
machines that I got. And the floppy set and boxed manual set were with
it. It had been installed, but whoever never got a license key. I
wound up contacting them and getting one for free, as they were
considering it old product by then. Then I never really tried to use
it. I had troff and a LaserJet, so I didn't need it. :-)
>> It *did* make it easier to break into a system which you had
>> lost the password for. Log in as guest (by default no password), send
>> yourself some e-mail, then click on the mail icon when it popped up, and
>> bang out of the mail program to a root shell. :-)
>
> Yeah, I remember that. Kind of like iPhones that all over the world have
> the same root password. ;-)
Ouch! I don't have one. Do they even give you access to change
the password? Do they warn you that it should be changed.
[ ... ]
>>> Actually, I can't imagine a businessman using a 3B2 at all. :-) But then,
>>> that wasn't the target market.
>>
>> But he *was* the target for the 3B1. Pretty raked styling, with
>> the floppy drive hiding behind the keyboard.
>
> And still they couldn't make a sucess of them.
Except in the hardware and software hacker crowd after the "fire
sale". :-)
I even got the hardware reference manual for the 3B1 -- full
schematics and excellent documentation. I was rather tempted to go into
the box and replace the array of RAM chips with four 1Mx9 DIMMs -- so
there would be no need for any extra RAM in the COMBO cards. Just two
serial ports per card. :-)
[ ... ]
>>> Yeah, I have a couple of QBUS M68K cards that would make great OS9-68K
>>> machines. And, it's ROMable!!
>>
>> I actually have such as set of Qbus cards too.
>
> Integrated Solutions?
I don't know. The cards are out in /dev/barn01, with a lot of
stuff which I would need to move to reach them, and I don't have the
cage to plug them into.
Right now -- even if I had lights in that building -- I would
not go out. It is bloody cold out there right now, and I doubt that I
could touch anything without launching a static zap. Ask me in the
summertime when the head and humidity will just about kill me before I
dig that far back. :-)
> If so, which PROMs? They had two. One booted a
> version of Unix (which I have not been able to find) and the other was
> MIKBUG (I think). Mine have the Unix boot PROMs. :-(
How do I tell? Especially without a card cage to run them in.
>> And with the 68K's address space, you could put the whole OS
>> including device drivers and device descriptors in ROM (except for
>> something which you were developing) and have plenty of address space
>> left for your applications.
>>
>> Even on a SWTP 6809, with 56 K of RAM, and a lot of OS-9 in 4K
>> of EPROM there was enough room so my wife and I could use it as the same
>> time, as long as I avoided running a big Pascal compile, or used the
>> work processor (Stylo, IIRC.)
>
> OS-9 was rather amazing that way. Imagine the looks on people's faces
> when I demoed three people logged into a Tandy Color Computer with 1 floppy
> and two serial ports (one bit banger and one UART based) and, of course,
> the console. And, I hears it was possible to modify the RS232 PAK so
> that with a MultiPAK interface you could even have two more serial
> ports and support users on all of them. All with a 6809 and 64K of
> memory.
Yep! And the later CoCos actually had 128K of RAM, and ran
Level-2 OS-9.
[ ... ]
>>> While possible, based on my experience with who actually used 3B2's I
>>> think it unlikely. While the machine (and CPU) had great promise they
>>> were really pretty crippled, as delivered, unless you had lots of money.
>>> And their lifetime was so short that even that didn't help by the time
>>> most of them made it into the hands of people who would play with them.
>>> Sad really.
>>
>> The 3B1 became a true hacker's machine. I've only heard of a
>> few 3B2 machines in hobby hands.
>
> Probably because without a supply of spare parts they ended out in the
> dumpster like both of mine. NCR did a good job of destroying everything
> as they did their "upgrades".
Ouch!
[ ... ]
>> Try what one friend encountered when bringing a big military
>> surplus transmitter home in the trunk of a car. He and his friend could
>> *barely* lift it -- but the car kept following it up, so getting it clear
>> of the trunk was a major problem. :-)
>
> T-368? :-)
Probably. I don't remember the model, as I never saw it. I
only heard about it years later.
[ ... ]
>>>> Was Sun in business by then? They started with the 68K
>>>> processors.
>>>
>>> Yeah, missed them in the list. And, I am sure a couple others. Siemans
>>> and Bull were already making Unix boxes by this point and may have also
>>> used M68K's. Of course, IBM had an M68K box as well. Target was labs.
>>> This was before the PC or their RISC systems.
>>
>> Wasn't Apollo in the 68K game too?
>
> Yeah, forgot them on my list as well. And I even had one of them.
I wonder how many others we have missed between us?
>>>> My 1/120 had a 10 MHz 68010 (same as the 3B1, but BSD
>>>> flavor). I *think* that the original SUN had the 68000 plain vanilla,
>>>> like my Coamos CMS-16/UNX.
>>>
>>> Yep. I know of a number of M68K Sun's still running.
>>
>> I've got quite a few which *could* run, but the power versus
>> computron ratio says that I run the UltraSPARCs for most things. :-)
>
> Speaking of SUN 3's..... Know anybody who might be interested in a pair
> of Deskside pedestal model 3's?
Which ones? The three slot 3/140, or the 12 slot 3/[12]60?
I've got examples of both. And I can't find anyone who wants them.
Though I did find someone who wanted the two spare 2/120s and the two
sidecars with two 8" 168MB SMB drives in each. His car (a rental which
was headed back up to the Boston area) was really riding low when he
pulled away. :-)
> I just checked and the Physics department
> still has their but need to get rid of them real soon now before the move
> to the new Science Building.
Hmm ... You know that they could be upgraded to SPARC based
systems with the 4/??? cards -- still use most of the existing cards,
except for the CPU card itself. And you could replace a lot of big RAM
boards with a single one full of 4Mx9 SIMMs.
Of course, I think that they could not run anything past perhaps
Solaris 2.6 -- if that far up the tree. :-)
Mine I was running SunOs 4.1.4 for a few years after the other
boxes started to get Solaris 2.x in them.
>>>>> That's what the IBM PC was supposed to be, but that's another story.
>>>>
>>>> That would have been an interesting twist to history. I wonder
>>>> where things would be if that had happened?
>>>
>>> Well, for one thing, MS would likely have never got the stranglehold on
>>> the industry they have.
>>
>> Exactly. They didn't know where to steal an OS for the 68K. :-)
>
> Actually, they already had M68K based desktop systems. Ran Unix.
And they could not imagine that a user would want unix, I guess. :-)
Or -- they couldn't make it into a closed system the way they
have with Windows. :-)
>> Now, if the PC had started with the 6809 and OS-9 it would have
>> been a *much* more attractive machine to me. :-)
>
> 6809 was already deadend technology by that point.
It was more powerful than the 8088 which the PC started with.
And it had as much a claim to being a 16-bit processor as the 8088 did. :-)
>>
>> [ ... ]
>>
>>
>> If you are interested, I could pull out the quad LSI-11 card and
>> list the chips present -- especially if you could point me to any other
>> than the four 40-pin ones which might be important.
>
> I sent a dual-wide LSI-11/02 to a guy out west and as far as I know it made
> his work. I never saw a quad-wide 11/02. 11/03, yes, but not an 11/02.
I may be mis-remembering what it was called, as it did not have
any clear labeling on it. Wasn't the quad-wide the earlier CPU, and the
dual-wide was a later one? (By quad-wide, I mean four edge connectors,
if there is any doubt there.)
>> The card cage is weird. One slot for the LSI-11/02 with the
>> standard DEC connectors, and the rest are a totally different bus, unique
>> to the Bridgeport box. :-)
>
> Didn't know that. I was always led to believe that the Bridgeport had a
> complete, real PDP-11 in it with custom QBUS boards to interface to the
> real machine. I have never actually seen one.
The only genuine DEC board was the quad-wide CPU. Everything
else was a wider card with totally different edge connectors, and my
machine (SN "CNC 103" (or was it "CNC 107"?) was supposed to be a very
early one, that they started with "CNC 100". In any case, the boards
were all wire wrap boards on that machine, but by the time the BOSS-5
version came out, all the boards were etched boards which fit in the
same bus.
DoN. Nichols
> On Jan 15, 6:13 am, arn...@skeeve.com (Aharon Robbins) wrote:
>> [...]
>> All of the talk about old computers is pretty amazing.
>
> Heh, it is. :-)
>
> But unless one has plenty of free time, "playing" with
> them is an extravagance. Still, I booted up one of my 3B1
> systems recently to retrieve some old files and it took
> a l-o-n-g time to boot.
Yep! Though the SGI Indigo 2 teal with the weird CPU which is
as fast for floating point math as for integer (but stuck at 75 MHz) is
quite slow to boot, too.
> I still have all the StarLAN stuff, too, including the
> StarLAN:RS-232 boxes and a ton of software and manuals.
> I'm going to have to get rid of the stuff soon, though,
> as I'm totally out of room.
Was it you who had the one and only SCSI card for a 3B1? I
remember that it was one of the regulars.
> Here's my desk about two
> months ago: <http://thadlabs.com/PIX/Thad_desk.jpg>.
> There's 18 computers visible in that photo. My 3B1s and
> a bunch of Suns are in my garage and another room along
> with my Amigas, a massive C64, and a Convergent Mitiframe.
That last one I don't remember hearing about. I do remember a
Convergent MiniFrame, but never saw one in the silicon.
:-)
[ ... ]
>> My main system is still called skeeve; it has just gone through it's
>> fourth regeneration to a different architecture (MC68010 -> Sun SPARC ->
>> Intel x86 -> x86_64). The difference in capabilities vs. cost from then
>> to now is amazing...
>
> Ain't that the truth! Almost everything in the above picture
> w-a-y outperforms a Cray-1 and I paid less than US$300 each new
> for them (mostly Intel Core Duo and AMD x64) with another one
> arriving Monday. Most of them double or triple boot (since I
> only have a 16 port KVM for the PC hardware and a Lightwave KVM
> for the Sun boxes all feeding the one NEC LCD seen in the photo).
:-)
> Argh, when I think of what I paid for my 3B1 systems new or,
> worse, for my first Sun-3/60 new. One of my $300 systems triple
> boots into Vista, Fedora 10 and Solaris 10; you can see its
> configuration from a Solaris point of view here:
>
><http://thadlabs.com/FILES/sysconfig.txt>
>
> Computers are truly a commodity item today. :-)
Yes. But I prefer the more interesting boxen. My current
workhorse is a Sun Blade 2000 with dual 1.2 GHz CPUs. I do have a few
Intel boxen -- one Windows which is almost never on, a Mac Mini which
gets more use and is actually allowed to see the outside net, and a
Shuttle with OpenBSD in it.
Thad Floryan
>
> UUNET seems to be dead, but ftp.uu.net still is out there -- it
> just hasn't been updated in years.
>
> I use it as the general target for ping or traceroute when I
> have doubts about how my net connection is doing. :-)
Ditto.
> [...]
> I even got the hardware reference manual for the 3B1 -- full
> schematics and excellent documentation. I was rather tempted to go into
> the box and replace the array of RAM chips with four 1Mx9 DIMMs -- so
> there would be no need for any extra RAM in the COMBO cards.
The COLOR 3B1 had DIMM sockets. It also was MC68020-based. Apparently
only two were (hand-cobbled) made. I had one of them, but it went
out with 1-800-GOT-JUNK a few year ago.
> [...]
> > OS-9 was rather amazing that way. Imagine the looks on people's faces
> > when I demoed three people logged into a Tandy Color Computer with 1 floppy
> > and two serial ports (one bit banger and one UART based) and, of course,
> > the console. And, I hears it was possible to modify the RS232 PAK so
> > that with a MultiPAK interface you could even have two more serial
> > ports and support users on all of them. All with a 6809 and 64K of
> > memory.
>
> Yep! And the later CoCos actually had 128K of RAM, and ran
> Level-2 OS-9.
For many years I'd demo a 3B1 (or two) at the West Coast Computer
Faire in San Francisco. The system(s) would be running EMACS, gcc
and asteroids simultaneously. DOS weenies would be agape.
Thad Floryan
> On 2009-01-15, Thad Floryan <t...@thadlabs.com> wrote:
>
> > I still have all the StarLAN stuff, too, including the
> > StarLAN:RS-232 boxes and a ton of software and manuals.
> > I'm going to have to get rid of the stuff soon, though,
> > as I'm totally out of room.
>
> Was it you who had the one and only SCSI card for a 3B1? I
> remember that it was one of the regulars.
No, it was someone else. People seem to forget the price of
SCSI disks back then. I bought one of the largest, a Maxtor
XT-3380 (380 MB) for one of my Amiga systems, and the Maxtor
cost $3,500.
> [...]
> That last one I don't remember hearing about. I do remember a
> Convergent MiniFrame, but never saw one in the silicon.
I had about five of the MiniFrames. Basically a 3B1 by design
but in a tower case. Could stick IIRC 3 or 4 disks in it. The
MitiFrame was a larger version with large expansion cards and
even the tape drive was built into the case. Mine has some
64 RS-232 ports and was the college "mainframe" for the College
of San Mateo (California).
A good friend of mine worked for Convergent and I'd get all the
"goodies" they'd conjure up even if they wouldn't become a
commercial product (such as the color 3B1).
Bill Gunshannon
"DoN. Nichols" <dnic...@d-and-d.com> writes:
> On 2009-01-15, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>> In article <slrngmtmo2....@katana.d-and-d.com>,
>> "DoN. Nichols" <dnic...@d-and-d.com> writes:
>
> [ ... ]
>
>>>
>>> At least I was using uucp go get mine -- from uunet before they
>>> changed the modems used from Telebit TrailBlazers to something which was
>>
>> I still have a pair of TrailBlazers in my collection.
>
> As do I. (Actually, I think that one is a WorldBlazer.
I would have to look, mine might be the same, one of each. That was a
long time ago.
>
> [ ... ]
>
>>> Ah yes -- the bang paths!
>>>
>>>> Remember the group mail.maps?
>>>
>>> Yep! One of the advantages of using uunet was that I could use
>>> a FQDN to both send and receive e-mail, though the first hop was uucp.
>>> So I did try to bring up the maps package, but it cost too much
>>> bandwidth to keep it updated, so I just used the domain names. IIRC, it
>>> looked something like this:
>>>
>>> ceilidh!uunet!username@FQDN
>>>
>>
>> I keep trying to convince people that we really need to revive this email
>> system. It offers the best and quickest solution to the SPAM problem but
>> apparently I am the only one who can see that.
>
> You know -- I think that would work! (Of course, it would bring
> most uses of email to its knees given today's user base. :-)
Why? It could, thoretically reduce the amount of email traversing
the network by, easily, an order of magnitude as there is at least
that much junk. If anything, it would increase the performance.
The only shortcoming in the concept of UUCP based Email is eliminated
by the use of the INTERNET as the transport medium. Seriously, what
would you see as the shortcomings of this idea?
>
>>>> And, the 3B2 had no TCPIP. Eventually
>>>> Woolongong did one but AT&T never did that I was aware of. That was
>>>> a Berkeley thing, not SYS V.
>>>
>>> The 3B1 used the WillGoWrong TCP/IP package -- with certain
>>> problems:
>>>
>>> 1) There was *no* ping -- because the kernel lacked the microtime
>>> function needed for that to work.
>>>
>>> 2) A "ping -f" from a Sun 2/120 was enough to crash the system.
>>>
>>
>> Do you remember when it was also the TCPIP package on VMS?
>
> I never ran VMS -- or even accessed a machine running it. I've
> got a friend who has been collecting VAXen in all sizes, and does run
> VMS at home on one or two of the smaller ones. Not enough power to spin
> up the larger ones, let alone not enough room. :-)
I dumped all my big disks (RA-series and Fuji Eagles) but VAXen can
use smaller, more modern disks. I have a number of VAXStation-3100's
that use SCSI and sit on a desktop running VMS quite well.
>
>> Of course,
>> I think they were also the ones who gave us "Eunice". :-)
>
> Oh yes -- the only experience with "Eunice" that I have is the
> comment from Larry Wall's "configure" script "Oh good! You're not
> running Eunice." which told me that it must be pretty bad. :-)
Probably the first attempt at what later became known as POSIX. :-)
Actually, it worked OK. It was near the resource hog the first Ada
compiler was!! :-)
>
> [ ... ]
>
>>> Yep! I was mostly only carrying comp.sys.3b1, comp.sources.3b1,
>>> alt.folklore.computers, alt.folklore.urban, comp.unix.wizards, and a few
>>> others -- but not much at uunet's connect time charges. :-)
>>>
>>
>> Remember where UUNET came from?
>
> I really never knew -- though I did know that they were local,
There used to be a site called "seismo". It grew gradually to become
the center of USENET and the non-AT&T UUCPNET. Then one day, someone
at the government realized that the machine, in a government site, run
by the government, consuming government resources was not doing government
business and ordered it to be shut down. This would have been rather
a disaster to USENET and a lot of people's email. So, sapce was rented
and a new machine set up to take over the job of being the hub of USENET
and UUCPNET and UUNET was born. It took on a life of its own and the
rest, as they say, is history. I think Rick Adams did nicely by that
particular venture. Too bad other people didn't have the same vision
he had or things might have developed much better than they have.
> and even once visited them (before they moved) to pick up an Exabyte
> tape of the sources tree.
>
> UUNET seems to be dead, but ftp.uu.net still is out there -- it
> just hasn't been updated in years.
Domain belongs to Verizon. ;-(
>
> I use it as the general target for ping or traceroute when I
> have doubts about how my net connection is doing. :-)
>
>> I tried to sell the Tech Center people
>> here on the practicality of a business offering Email and News using
>> UUNET as my business case. This was before the first ISP or even the
>> INTERNET (outside of the University where I had been hired to set it up)
>> existed in NEPA. They could not see where anyone would be willing to
>> pay money for something like Email or News. :-(
>
> Interesting. *I* certainly was willing to do so -- even while
> working for an Army lab and getting access to Arpanet at the time.
Yeah, that was a great example of the shortsightedness of people around
here. I had a similar experience with a local PC company who contracted
me to set them up in the ISP business. After many hours of work I showed
up one day, not too long before we would have gone live, to find the
servers I was building wiped and loaded with Windows. I was told they
decided not to pursue that line of business. They gave me a check for
what they thought my work was worth and told me goodbye. I could have
sued them for breach of contract in order to get the rest of my money
but decided it wasn't worth the headache. I have never done any contract
work around here since and never would.
>
> [ ... ]
>
>>> It *did* make it easier to break into a system which you had
>>> lost the password for. Log in as guest (by default no password), send
>>> yourself some e-mail, then click on the mail icon when it popped up, and
>>> bang out of the mail program to a root shell. :-)
>>
>> Yeah, I remember that. Kind of like iPhones that all over the world have
>> the same root password. ;-)
>
> Ouch! I don't have one. Do they even give you access to change
> the password?
Sure. it's just a linux box in your pocket. Has an sshd available.
> Do they warn you that it should be changed.
It can't be changed. If you change it, the phone don't work anymore.
Luckily, there is no daemon accepting incoming connections by default,
but many people turn on ssh. And, one never knows what gets done when
you visit one of those whiz-bang web sites. :-)
I had a really neat demonstration of using a hacked iPhone as a bug.
Demonstrator passed an iPhone around the room and while it was making
the rounds he turned on the microphone and recorded all the conversations
on his PC. Afterwards, he played it all back. There was no way we could
tell from looking at the iPhone that he was doing this. It's as scary
as OnStar!!
>
> [ ... ]
>
>>>> Yeah, I have a couple of QBUS M68K cards that would make great OS9-68K
>>>> machines. And, it's ROMable!!
>>>
>>> I actually have such as set of Qbus cards too.
>>
>> Integrated Solutions?
>
> I don't know. The cards are out in /dev/barn01, with a lot of
> stuff which I would need to move to reach them, and I don't have the
> cage to plug them into.
You want one? :-) of course, you'll need more QBUS modules if you
actually want to use it.
>
> Right now -- even if I had lights in that building -- I would
> not go out. It is bloody cold out there right now,
Not as cold as here. I had pipes wrapped with an electric heat-tape
and insulation that were frozen this morning. Got to move south!!
> and I doubt that I
> could touch anything without launching a static zap. Ask me in the
> summertime when the head and humidity will just about kill me before I
> dig that far back. :-)
>
>> If so, which PROMs? They had two. One booted a
>> version of Unix (which I have not been able to find) and the other was
>> MIKBUG (I think). Mine have the Unix boot PROMs. :-(
>
> How do I tell? Especially without a card cage to run them in.
Well, you can read the label on the PROM if it's still there, otherwise,
you have to fire ut up and see what you get for a prompt.
>
>>> And with the 68K's address space, you could put the whole OS
>>> including device drivers and device descriptors in ROM (except for
>>> something which you were developing) and have plenty of address space
>>> left for your applications.
>>>
>>> Even on a SWTP 6809, with 56 K of RAM, and a lot of OS-9 in 4K
>>> of EPROM there was enough room so my wife and I could use it as the same
>>> time, as long as I avoided running a big Pascal compile, or used the
>>> work processor (Stylo, IIRC.)
>>
>> OS-9 was rather amazing that way. Imagine the looks on people's faces
>> when I demoed three people logged into a Tandy Color Computer with 1 floppy
>> and two serial ports (one bit banger and one UART based) and, of course,
>> the console. And, I hears it was possible to modify the RS232 PAK so
>> that with a MultiPAK interface you could even have two more serial
>> ports and support users on all of them. All with a 6809 and 64K of
>> memory.
>
> Yep! And the later CoCos actually had 128K of RAM, and ran
> Level-2 OS-9.
Yeah, I got that, too. :-)
>
> [ ... ]
>
>>> Try what one friend encountered when bringing a big military
>>> surplus transmitter home in the trunk of a car. He and his friend could
>>> *barely* lift it -- but the car kept following it up, so getting it clear
>>> of the trunk was a major problem. :-)
>>
>> T-368? :-)
>
> Probably. I don't remember the model, as I never saw it. I
> only heard about it years later.
I used to be a radio teletype operator int he Army and remember that
one well. I know a number of them have ended out in surplus and went
to ham operators. There's a group that meets on 80M that runs AM and
I know at least one of these guys is using one. Draws more power than
my biggest old iron computer!!
>
> [ ... ]
>
>>
>> Speaking of SUN 3's..... Know anybody who might be interested in a pair
>> of Deskside pedestal model 3's?
>
> Which ones? The three slot 3/140, or the 12 slot 3/[12]60?
> I've got examples of both. And I can't find anyone who wants them.
Don't know, have to go look. I may roll them up here later today. The
only part I really want is the 9-track. I definitely don't want the
Fuji eagle. I would hate to see them go to the skip, but if I can't
find a home for them, they will.
> Though I did find someone who wanted the two spare 2/120s and the two
> sidecars with two 8" 168MB SMB drives in each. His car (a rental which
> was headed back up to the Boston area) was really riding low when he
> pulled away. :-)
>
>> I just checked and the Physics department
>> still has their but need to get rid of them real soon now before the move
>> to the new Science Building.
>
> Hmm ... You know that they could be upgraded to SPARC based
> systems with the 4/??? cards -- still use most of the existing cards,
> except for the CPU card itself. And you could replace a lot of big RAM
> boards with a single one full of 4Mx9 SIMMs.
>
> Of course, I think that they could not run anything past perhaps
> Solaris 2.6 -- if that far up the tree. :-)
This place has abandoned all of that. We used to have a bunch of Sparc
here but I just took the last one (an UltraSparc) home. All the rest
were either given away or trashed. :-(
>
> Mine I was running SunOs 4.1.4 for a few years after the other
> boxes started to get Solaris 2.x in them.
I never liked Solaris. I think they should have stayed with SunOS.
>
>>>>>> That's what the IBM PC was supposed to be, but that's another story.
>>>>>
>>>>> That would have been an interesting twist to history. I wonder
>>>>> where things would be if that had happened?
>>>>
>>>> Well, for one thing, MS would likely have never got the stranglehold on
>>>> the industry they have.
>>>
>>> Exactly. They didn't know where to steal an OS for the 68K. :-)
>>
>> Actually, they already had M68K based desktop systems. Ran Unix.
>
> And they could not imagine that a user would want unix, I guess. :-)
No, had nothing to do with what they could run on it. Had to do with
politics and control. Nothing technical in the decision at all.
>
> Or -- they couldn't make it into a closed system the way they
> have with Windows. :-)
Actually, PC's, with the exception of the the PS/2 and MCA, were never
closed. In those days IBM could sell based solely on their name and
didn't really worry about cloning. (Aside: I know a local company that
paid 3 times as much for SIMMS for their PS/2 from IBM over what it
would have cost to get it from Kingston because they insisted it say
IBM on the box. The memory they got was Kingston Memory rebadged and
shipped in an IBM box.)
>
>>> Now, if the PC had started with the 6809 and OS-9 it would have
>>> been a *much* more attractive machine to me. :-)
>>
>> 6809 was already deadend technology by that point.
>
> It was more powerful than the 8088 which the PC started with.
> And it had as much a claim to being a 16-bit processor as the 8088 did. :-)
But suffered fromt he same problem that IBM found with their idea to use
the M68K. :-)
A most interesting conversation. I wonder if anyone else is reading and
enjoying the reminisce? The most traffic this group has seen in a long
time.
Bill Gunshannon
"DoN. Nichols" <dnic...@d-and-d.com> writes:
> On 2009-01-15, Thad Floryan <th...@thadlabs.com> wrote:
>> On Jan 15, 6:13 am, arn...@skeeve.com (Aharon Robbins) wrote:
>>> [...]
>>> All of the talk about old computers is pretty amazing.
>>
>> Heh, it is. :-)
>>
>> But unless one has plenty of free time, "playing" with
>> them is an extravagance. Still, I booted up one of my 3B1
>> systems recently to retrieve some old files and it took
>> a l-o-n-g time to boot.
>
> Yep! Though the SGI Indigo 2 teal with the weird CPU which is
> as fast for floating point math as for integer (but stuck at 75 MHz) is
> quite slow to boot, too.
Well, XP and Vista aren't what I would call speed demons when it comes
to booting either....
>
>> I still have all the StarLAN stuff, too, including the
>> StarLAN:RS-232 boxes and a ton of software and manuals.
>> I'm going to have to get rid of the stuff soon, though,
>> as I'm totally out of room.
>
> Was it you who had the one and only SCSI card for a 3B1? I
> remember that it was one of the regulars.
>
>> Here's my desk about two
>> months ago: <http://thadlabs.com/PIX/Thad_desk.jpg>.
>> There's 18 computers visible in that photo. My 3B1s and
>> a bunch of Suns are in my garage and another room along
>> with my Amigas, a massive C64, and a Convergent Mitiframe.
>
> That last one I don't remember hearing about. I do remember a
> Convergent MiniFrame, but never saw one in the silicon.
I have seen (and actually used) a MiniFrame. I remember hearing about the
MitiFrame but never saw one.
Bill Gunshannon
Thad Floryan <th...@thadlabs.com> writes:
> On Jan 15, 10:44 pm, "DoN. Nichols" <dnich...@d-and-d.com> wrote:
>> On 2009-01-15, Thad Floryan <t...@thadlabs.com> wrote:
>>
>> > I still have all the StarLAN stuff, too, including the
>> > StarLAN:RS-232 boxes and a ton of software and manuals.
>> > I'm going to have to get rid of the stuff soon, though,
>> > as I'm totally out of room.
>>
>> Was it you who had the one and only SCSI card for a 3B1? I
>> remember that it was one of the regulars.
>
> No, it was someone else. People seem to forget the price of
> SCSI disks back then. I bought one of the largest, a Maxtor
> XT-3380 (380 MB) for one of my Amiga systems, and the Maxtor
> cost $3,500.
Back then? Have you compared the price of SCSI to IDE or SATA even
today?
Thad Floryan
> In article <dabc4d04-3098-4211-958c-26fd4c5a6...@i18g2000prf.googlegroups.com>,
> Thad Floryan <t...@thadlabs.com> writes:
> > No, it was someone else. People seem to forget the price of
> > SCSI disks back then. I bought one of the largest, a Maxtor
> > XT-3380 (380 MB) for one of my Amiga systems, and the Maxtor
> > cost $3,500.
>
> Back then? Have you compared the price of SCSI to IDE or SATA even
> today?
Though I can buy a Seagate 1TB SATA drive for US$100 today (from,
for example, Frys Electronics), such consumer drives simply are
not suitable for enterprise applications (though using RAID can
help if one has a supply of spares handy). Today's SCSI drives'
pricing is nowhere near 1985's $3,500.
Today's prices are chump change. I just bought another $300
system yesterday (arriving Monday) with 4GB RAM, two 500GB HD,
and Intel Core 2 Duo at 2.2GHz; it'll be another test server.
Thad Floryan
>
> Well, XP and Vista aren't what I would call speed demons when it
> comes to booting either....
I agree about XP -- it's a dog.
But a properly setup Vista system boots and is ready for use
faster than any of my Linux or Solaris systems.
I wsa pleasantly surprised after buying my first system
May 2008 to run Microsoft's WorldWideTelescope program
(noting astronomy has been a hobby of mine over 50 years),
and I learned how to tweak Vista. I likeed it so much I
now have 5 Vista systems.
Most people who dis Vista haven't bothered to learn it,
same as how and why people dis Linux and UNIX.
Vista is modular and, using free tools from Microsoft,
I even created a Vista Live CD which, with its tools.
I can fix other systems (e.g., dogs like XP). What
confuses most people is how the directory hierarchy
has changed to be like UNIX. Vista's equivalent to
UNIX's /home/username is \Users\username, and all the
XP and prior junk such as "Documents and Folders" are
now junctions (akin to symlinks). Vista is great if
one bothers to learn the details (which most reviewers
and users don't).
Wanna see something interesting? A major UNIX app I
got to work on Vista as you can see here:
<http://thadlabs.com/PIX/xephem.jpg>
I use XEphem to study astronomical events and produce
charts for use at the scope, such as these planetary
retrogrades:
<http://thadlabs.com/FILES/Mars_retro_2003.pdf>
<http://thadlabs.com/FILES/Mars_retro_2005.pdf>
<http://thadlabs.com/FILES/Mars_retro_2007.pdf>
<http://thadlabs.com/FILES/Mars_retro_2010.pdf>
<http://thadlabs.com/FILES/Jupiter_retro_2008_overall.pdf>
<http://thadlabs.com/FILES/Jupiter_retro_2008_detail.pdf>
<http://thadlabs.com/FILES/Jupiter_retro_2008_magnif.pdf>
tlvp
<bill...@cs.uofs.edu> wrote, in part:
>
>> [ ... ]
>
> I keep trying to convince people that we really need to revive this email
> system. It offers the best and quickest solution to the SPAM problem but
> apparently I am the only one who can see that.
How you feel about uucp mail is how I feel about attmail -- nice, clean,
text-only email that, while it can allow spam to enter, cannot allow any
virus, worm, trojan, or other malware to *run*.
My first eye-opener to the big bad world of the unbridled internet came
from seeing the actual HTML iFrame invocations meant to download and then
run the Romeo.com and Juliet.exe components of the old Romeo & Juliet
virus.
(This was while on attmail, via modem and dumb terminal.) Kept me from ever
wanting HTML mail at all.
What I do *not* miss at all, though, is having to construct one's own
bang-path, absent any reliable DNS info, to whomever you wanted to send
mail to.
Cheers, and thanks to you, DoN, Thad, Lenny, and others, for the 3b1
memories.
-- tlvp
Bill Gunshannon
tlvp <PmUiRsGcE...@att.net> writes:
> On Thu, 15 Jan 2009 10:07:50 -0500, Bill Gunshannon
> <bill...@cs.uofs.edu> wrote, in part:
>
>>
>>> [ ... ]
>>
>> I keep trying to convince people that we really need to revive this email
>> system. It offers the best and quickest solution to the SPAM problem but
>> apparently I am the only one who can see that.
>
> How you feel about uucp mail is how I feel about attmail -- nice, clean,
> text-only email that, while it can allow spam to enter, cannot allow any
> virus, worm, trojan, or other malware to *run*.
Ummm.... I think you have a poor understanding of uucp email. It is not
necessarily text only, no more than 7bit-clean SMTP. With MIME you can
send pretty much anything. But then, actually receiving a "virus, worm,
trojan, or other malware" from a legitimate email is highly unlikely.
As for SPAM, my sugestion makes it become pretty much non-existant.
There would be no zombied machines capable of injecting SPAM into the
system and an actual SPAMer will get one shot and then find themselves
cut off from the world of email as well as possibly being found financially
liable for their actions.
>
> My first eye-opener to the big bad world of the unbridled internet came
> from seeing the actual HTML iFrame invocations meant to download and then
> run the Romeo.com and Juliet.exe components of the old Romeo & Juliet
> virus.
> (This was while on attmail, via modem and dumb terminal.) Kept me from ever
> wanting HTML mail at all.
>
> What I do *not* miss at all, though, is having to construct one's own
> bang-path, absent any reliable DNS info, to whomever you wanted to send
> mail to.
Believe it or not, with the computing power available today and a revival
comp.mail.maps, that would not be a problem at all. One could easily use
the user@address syntax and let the email system get it there, kind of like
the way it does it now. :-)
>
> Cheers, and thanks to you, DoN, Thad, Lenny, and others, for the 3b1
> memories.
I fear like so muc of out history many of these memories are not long
for this world.
DoN. Nichols
> On Jan 15, 10:32 pm, "DoN. Nichols" <dnich...@d-and-d.com> wrote:
>
>>
>> UUNET seems to be dead, but ftp.uu.net still is out there -- it
>> just hasn't been updated in years.
>>
>> I use it as the general target for ping or traceroute when I
>> have doubts about how my net connection is doing. :-)
>
> Ditto.
I wonder why it is still up -- and who is paying the electric
bill. :-)
>> [...]
>> I even got the hardware reference manual for the 3B1 -- full
>> schematics and excellent documentation. I was rather tempted to go into
>> the box and replace the array of RAM chips with four 1Mx9 DIMMs -- so
>> there would be no need for any extra RAM in the COMBO cards.
>
> The COLOR 3B1 had DIMM sockets. It also was MC68020-based. Apparently
> only two were (hand-cobbled) made. I had one of them, but it went
> out with 1-800-GOT-JUNK a few year ago.
A color one? 68020-based? Nice!
>> [...]
>> > OS-9 was rather amazing that way. Imagine the looks on people's faces
>> > when I demoed three people logged into a Tandy Color Computer with 1 floppy
>> > and two serial ports (one bit banger and one UART based) and, of course,
>> > the console. And, I hears it was possible to modify the RS232 PAK so
>> > that with a MultiPAK interface you could even have two more serial
>> > ports and support users on all of them. All with a 6809 and 64K of
>> > memory.
>>
>> Yep! And the later CoCos actually had 128K of RAM, and ran
>> Level-2 OS-9.
>
> For many years I'd demo a 3B1 (or two) at the West Coast Computer
> Faire in San Francisco. The system(s) would be running EMACS, gcc
> and asteroids simultaneously. DOS weenies would be agape.
It did not take much to do that to them. :-)
DoN. Nichols
> In article <slrngn0af1....@katana.d-and-d.com>,
> "DoN. Nichols" <dnic...@d-and-d.com> writes:
>> On 2009-01-15, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>>> In article <slrngmtmo2....@katana.d-and-d.com>,
>>> "DoN. Nichols" <dnic...@d-and-d.com> writes:
[ ... ]
>>>> ceilidh!uunet!username@FQDN
>>>>
>>>
>>> I keep trying to convince people that we really need to revive this email
>>> system. It offers the best and quickest solution to the SPAM problem but
>>> apparently I am the only one who can see that.
>>
>> You know -- I think that would work! (Of course, it would bring
>> most uses of email to its knees given today's user base. :-)
>
> Why? It could, thoretically reduce the amount of email traversing
> the network by, easily, an order of magnitude as there is at least
> that much junk. If anything, it would increase the performance.
> The only shortcoming in the concept of UUCP based Email is eliminated
> by the use of the INTERNET as the transport medium. Seriously, what
> would you see as the shortcomings of this idea?
What I was suggesting is that the user base would have to be
totally re-educated -- and a lot of them would fight it tooth and nail.
Aside from that -- bang paths are vulnerable to a single machine
in the path going out of service between the receipt of the incoming
e-mail and the sending of the reply.
But it would sure make it easy to track down the originator of
spam -- or at least the compromised machine sending it out. :-)
>>
>>>>> And, the 3B2 had no TCPIP. Eventually
>>>>> Woolongong did one but AT&T never did that I was aware of. That was
>>>>> a Berkeley thing, not SYS V.
>>>>
>>>> The 3B1 used the WillGoWrong TCP/IP package -- with certain
>>>> problems:
[ ... ]
>>> Do you remember when it was also the TCPIP package on VMS?
>>
>> I never ran VMS -- or even accessed a machine running it. I've
>> got a friend who has been collecting VAXen in all sizes, and does run
>> VMS at home on one or two of the smaller ones. Not enough power to spin
>> up the larger ones, let alone not enough room. :-)
>
> I dumped all my big disks (RA-series and Fuji Eagles) but VAXen can
> use smaller, more modern disks. I have a number of VAXStation-3100's
> that use SCSI and sit on a desktop running VMS quite well.
Sure -- but he had multi-bay machines which he could never run
as well. :-)
>>
>>> Of course,
>>> I think they were also the ones who gave us "Eunice". :-)
>>
>> Oh yes -- the only experience with "Eunice" that I have is the
>> comment from Larry Wall's "configure" script "Oh good! You're not
>> running Eunice." which told me that it must be pretty bad. :-)
>
> Probably the first attempt at what later became known as POSIX. :-)
> Actually, it worked OK. It was near the resource hog the first Ada
> compiler was!! :-)
Hmm ... I remember being shocked when I heard that DEC claimed
POSIX compliance for VMS. :-)
And, IIRC, the major problem with running unix-inspired things
on VMS was that process creation on unix was dirt cheap -- just a
"fork", However, on VMS, it was quite expensive, so a program which was
quite happy on even an old v7 unix machine would bring VMS to its knees.
[ ... ]
>>> Remember where UUNET came from?
>>
>> I really never knew -- though I did know that they were local,
>
> There used to be a site called "seismo".
That name sounds familiar.
> It grew gradually to become
> the center of USENET and the non-AT&T UUCPNET. Then one day, someone
> at the government realized that the machine, in a government site, run
> by the government, consuming government resources was not doing government
> business and ordered it to be shut down.
Hmm ... this reminds me of what happened to the system running
TOPS-20 -- a major repository of open source software. Ah yes -- I
remember the name now -- simtel20. Many's the time I telneted to that
from work -- and even some from home eventually.
> This would have been rather
> a disaster to USENET and a lot of people's email. So, sapce was rented
> and a new machine set up to take over the job of being the hub of USENET
> and UUCPNET and UUNET was born. It took on a life of its own and the
> rest, as they say, is history. I think Rick Adams did nicely by that
> particular venture. Too bad other people didn't have the same vision
> he had or things might have developed much better than they have.
Indeed so.
>> and even once visited them (before they moved) to pick up an Exabyte
>> tape of the sources tree.
>>
>> UUNET seems to be dead, but ftp.uu.net still is out there -- it
>> just hasn't been updated in years.
>
> Domain belongs to Verizon. ;-(
Sigh! So does the copper that my T1 comes through. And they
keep trying to push me onto FIOS -- but won't offer me static IPS, and
especially a Class-C block of IPs.
[ ... ]
>>> existed in NEPA. They could not see where anyone would be willing to
>>> pay money for something like Email or News. :-(
>>
>> Interesting. *I* certainly was willing to do so -- even while
>> working for an Army lab and getting access to Arpanet at the time.
>
> Yeah, that was a great example of the shortsightedness of people around
> here.
Where is "here"?
> I had a similar experience with a local PC company who contracted
> me to set them up in the ISP business. After many hours of work I showed
> up one day, not too long before we would have gone live, to find the
> servers I was building wiped and loaded with Windows. I was told they
> decided not to pursue that line of business. They gave me a check for
> what they thought my work was worth and told me goodbye. I could have
> sued them for breach of contract in order to get the rest of my money
> but decided it wasn't worth the headache. I have never done any contract
> work around here since and never would.
Ouch! You should have used machines which would not support
Windows -- then they couldn't do that. :-)
>>
>> [ ... ]
>>
>>>> It *did* make it easier to break into a system which you had
>>>> lost the password for. Log in as guest (by default no password), send
>>>> yourself some e-mail, then click on the mail icon when it popped up, and
>>>> bang out of the mail program to a root shell. :-)
>>>
>>> Yeah, I remember that. Kind of like iPhones that all over the world have
>>> the same root password. ;-)
>>
>> Ouch! I don't have one. Do they even give you access to change
>> the password?
>
> Sure. it's just a linux box in your pocket. Has an sshd available.
Yes -- but through what path? Does it have an ethernet jack?
Or are you stuck having to expose it to connections over the air?
>> Do they warn you that it should be changed.
>
> It can't be changed. If you change it, the phone don't work anymore.
That is terrible.
> Luckily, there is no daemon accepting incoming connections by default,
> but many people turn on ssh. And, one never knows what gets done when
> you visit one of those whiz-bang web sites. :-)
:-)
> I had a really neat demonstration of using a hacked iPhone as a bug.
> Demonstrator passed an iPhone around the room and while it was making
> the rounds he turned on the microphone and recorded all the conversations
> on his PC. Afterwards, he played it all back. There was no way we could
> tell from looking at the iPhone that he was doing this. It's as scary
> as OnStar!!
:-)
>>
>> [ ... ]
>>
>>>>> Yeah, I have a couple of QBUS M68K cards that would make great OS9-68K
>>>>> machines. And, it's ROMable!!
>>>>
>>>> I actually have such as set of Qbus cards too.
>>>
>>> Integrated Solutions?
>>
>> I don't know. The cards are out in /dev/barn01, with a lot of
>> stuff which I would need to move to reach them, and I don't have the
>> cage to plug them into.
>
> You want one? :-) of course, you'll need more QBUS modules if you
> actually want to use it.
Which -- the backplane? Yes, I would like one. There was a
suite of about four or five boards with it. IIRC, there is a ribbon
cable bus on the outside edge of the cards to supplement the Q-bus.
Now that I think of it -- it had apparently run Sys-III, and
I've still got a box of the OS manuals out in /dev/barn02 on top of a
rack full of stuff.
>>
>> Right now -- even if I had lights in that building -- I would
>> not go out. It is bloody cold out there right now,
>
> Not as cold as here. I had pipes wrapped with an electric heat-tape
> and insulation that were frozen this morning. Got to move south!!
Ouch! Where is "here"? I'm in Northern VA, FWIW.
>> and I doubt that I
>> could touch anything without launching a static zap. Ask me in the
>> summertime when the head and humidity will just about kill me before I
>> dig that far back. :-)
>>
>>> If so, which PROMs? They had two. One booted a
>>> version of Unix (which I have not been able to find) and the other was
>>> MIKBUG (I think). Mine have the Unix boot PROMs. :-(
>>
>> How do I tell? Especially without a card cage to run them in.
>
> Well, you can read the label on the PROM if it's still there, otherwise,
> you have to fire ut up and see what you get for a prompt.
Depends on whether the PROMs just had a label stuck on (which
may have faded or blown away) or whether they were metal-capped PROMs or
something with a MelInk stamped identifier. Hmm ... not EPROMs, but
bipolar single use ones?
>>>> And with the 68K's address space, you could put the whole OS
>>>> including device drivers and device descriptors in ROM (except for
>>>> something which you were developing) and have plenty of address space
>>>> left for your applications.
>>>>
>>>> Even on a SWTP 6809, with 56 K of RAM, and a lot of OS-9 in 4K
>>>> of EPROM there was enough room so my wife and I could use it as the same
>>>> time, as long as I avoided running a big Pascal compile, or used the
>>>> work processor (Stylo, IIRC.)
>>>
>>> OS-9 was rather amazing that way. Imagine the looks on people's faces
>>> when I demoed three people logged into a Tandy Color Computer with 1 floppy
>>> and two serial ports (one bit banger and one UART based) and, of course,
>>> the console. And, I hears it was possible to modify the RS232 PAK so
>>> that with a MultiPAK interface you could even have two more serial
>>> ports and support users on all of them. All with a 6809 and 64K of
>>> memory.
>>
>> Yep! And the later CoCos actually had 128K of RAM, and ran
>> Level-2 OS-9.
>
> Yeah, I got that, too. :-)
I never did pick up one of the expanded ones. About that time,
I was digging into multiple unix boxen, starting with the COSMOS
CMS16/UNX.
>> [ ... ]
>>
>>>> Try what one friend encountered when bringing a big military
>>>> surplus transmitter home in the trunk of a car. He and his friend could
>>>> *barely* lift it -- but the car kept following it up, so getting it clear
>>>> of the trunk was a major problem. :-)
>>>
>>> T-368? :-)
>>
>> Probably. I don't remember the model, as I never saw it. I
>> only heard about it years later.
>
> I used to be a radio teletype operator int he Army and remember that
> one well. I know a number of them have ended out in surplus and went
> to ham operators. There's a group that meets on 80M that runs AM and
> I know at least one of these guys is using one. Draws more power than
> my biggest old iron computer!!
Hmm ... how much power did it put into the final?
>>
>> [ ... ]
>>
>>>
>>> Speaking of SUN 3's..... Know anybody who might be interested in a pair
>>> of Deskside pedestal model 3's?
>>
>> Which ones? The three slot 3/140, or the 12 slot 3/[12]60?
>> I've got examples of both. And I can't find anyone who wants them.
>
> Don't know, have to go look. I may roll them up here later today.
If they roll, it is the 12-slot ones. You could carry the
three-slot one, and had to put it in a stand to keep it vertical if you
did not want to lay it down.
> The
> only part I really want is the 9-track.
Hmm ... I've got one here -- and nothing running the full VME
bus still up, so I can't load the interface card for it.
But I also have a SCSI-Interfaced HP one -- front loading self
threading machine. Not as much fun to watch as two spinning reels, but
it works rather well -- or did when I last used it.
> I definitely don't want the
> Fuji eagle. I would hate to see them go to the skip, but if I can't
> find a home for them, they will.
Indeed. I passed mine on to a regular from
alt.folklore.computers (I think it was -- maybe comp.sys.sun.hardware
instead) who moved to the area and started showing up on
rec.crafts.metalworking. :-)
Still have my Fujitsu M2312Ks (84 MB) which I used on the first
unix box here.
>> Though I did find someone who wanted the two spare 2/120s and the two
>> sidecars with two 8" 168MB SMB drives in each. His car (a rental which
>> was headed back up to the Boston area) was really riding low when he
>> pulled away. :-)
>>
>>> I just checked and the Physics department
>>> still has their but need to get rid of them real soon now before the move
>>> to the new Science Building.
>>
>> Hmm ... You know that they could be upgraded to SPARC based
>> systems with the 4/??? cards -- still use most of the existing cards,
>> except for the CPU card itself. And you could replace a lot of big RAM
>> boards with a single one full of 4Mx9 SIMMs.
>>
>> Of course, I think that they could not run anything past perhaps
>> Solaris 2.6 -- if that far up the tree. :-)
>
> This place has abandoned all of that. We used to have a bunch of Sparc
> here but I just took the last one (an UltraSparc) home. All the rest
> were either given away or trashed. :-(
Ouch! Which Ultra was it that you got? I've got Ultra-1
Ultra-5, Ultra-10, Ultra-60, the SF-280R, several SB-1000s and one
SB-2000 at present.
>>
>> Mine I was running SunOs 4.1.4 for a few years after the other
>> boxes started to get Solaris 2.x in them.
>
> I never liked Solaris. I think they should have stayed with SunOS.
Well ... there was a tradeoff. On the older machines, I
preferred SunOs 4.1.4 (or SunOs 4.1.1_U1 for the Sun-3 machines), but
for the Ultras, Solaris 10 is quite nice -- especially with zfs in there
giving me a very nice RAID-5 or two on a couple of systems.
The Ultra-5 and Ultra-10 machines are running OpenBSD, so they
feel more like SunOs 4.1.x, except that you can have 15 partitions
(exclusive of the whole disk) instead of only seven.
But Solaris 10 seems to be faster on the newer Ultras, and
OpenBSD has just barely begun to support more than one CPU on the
UltraSPARC machines.
Oh yes -- I just remembered another couple of machines which I
forgot to mention in the list. Solbourne S4000 and S4000DX. Soulbourne
was runing mult-processor on their SPARC systems back when Sun was
claiming that they had to move to Solaris so they *could* run
multi-processor. And for quite a while, I was running a SparcStation 10
with two ROSS double CPU cards in it. Four CPUs -- and to use them I
had to run SunOs 4.1.4 -- Solaris would not touch them because they did
not have on-card cache. :-)
[ ... ]
>>>>> Well, for one thing, MS would likely have never got the stranglehold on
>>>>> the industry they have.
>>>>
>>>> Exactly. They didn't know where to steal an OS for the 68K. :-)
>>>
>>> Actually, they already had M68K based desktop systems. Ran Unix.
>>
>> And they could not imagine that a user would want unix, I guess. :-)
>
> No, had nothing to do with what they could run on it. Had to do with
> politics and control. Nothing technical in the decision at all.
O.K. Well ... that figures. :-)
>> Or -- they couldn't make it into a closed system the way they
>> have with Windows. :-)
>
> Actually, PC's, with the exception of the the PS/2 and MCA, were never
> closed.
Right -- the early ones you could get all the data about the
system you wanted.
> In those days IBM could sell based solely on their name and
> didn't really worry about cloning. (Aside: I know a local company that
> paid 3 times as much for SIMMS for their PS/2 from IBM over what it
> would have cost to get it from Kingston because they insisted it say
> IBM on the box. The memory they got was Kingston Memory rebadged and
> shipped in an IBM box.)
But -- later versions of Windows keeps everything possible
hidden -- especially how to run things like the WinModems (which remind
me of the floppy drives used in the Apple-II. :-)
>>>> Now, if the PC had started with the 6809 and OS-9 it would have
>>>> been a *much* more attractive machine to me. :-)
>>>
>>> 6809 was already deadend technology by that point.
>>
>> It was more powerful than the 8088 which the PC started with.
>> And it had as much a claim to being a 16-bit processor as the 8088 did. :-)
>
> But suffered fromt he same problem that IBM found with their idea to use
> the M68K. :-)
Political?
> A most interesting conversation. I wonder if anyone else is reading and
> enjoying the reminisce? The most traffic this group has seen in a long
> time.
I think that some are.
I was away for a couple of days so I could catch up on other
active newsgroups. "comp.sys.3b1" comes early in the reading sequence,
and with all the typing I've been doing there, I would get to the other
newsgroups about time to go to bed. :-)
DoN. Nichols
>> On 2009-01-15, Thad Floryan <t...@thadlabs.com> wrote:
>>
>> > I still have all the StarLAN stuff, too, including the
>> > StarLAN:RS-232 boxes and a ton of software and manuals.
>> > I'm going to have to get rid of the stuff soon, though,
>> > as I'm totally out of room.
>>
>> Was it you who had the one and only SCSI card for a 3B1? I
>> remember that it was one of the regulars.
>
> No, it was someone else.
O.K. But you do remember that there was *someone*.
> People seem to forget the price of
> SCSI disks back then. I bought one of the largest, a Maxtor
> XT-3380 (380 MB) for one of my Amiga systems, and the Maxtor
> cost $3,500.
But it could have used the adaptor cards to talk to two MFM or
(whatever that other bus was) to act as SCSI drives. That was what Sun
was doing during the Sun-3 days.
>> [...]
>> That last one I don't remember hearing about. I do remember a
>> Convergent MiniFrame, but never saw one in the silicon.
>
> I had about five of the MiniFrames. Basically a 3B1 by design
> but in a tower case. Could stick IIRC 3 or 4 disks in it. The
> MitiFrame was a larger version with large expansion cards and
> even the tape drive was built into the case. Mine has some
> 64 RS-232 ports and was the college "mainframe" for the College
> of San Mateo (California).
O.K. That sounds impressive.
> A good friend of mine worked for Convergent and I'd get all the
> "goodies" they'd conjure up even if they wouldn't become a
> commercial product (such as the color 3B1).
A fun position to be in.
DoN. Nichols
> "DoN. Nichols" <dnic...@d-and-d.com> writes:
>> On 2009-01-15, Thad Floryan <th...@thadlabs.com> wrote:
[ ... ]
>>> But unless one has plenty of free time, "playing" with
>>> them is an extravagance. Still, I booted up one of my 3B1
>>> systems recently to retrieve some old files and it took
>>> a l-o-n-g time to boot.
>>
>> Yep! Though the SGI Indigo 2 teal with the weird CPU which is
>> as fast for floating point math as for integer (but stuck at 75 MHz) is
>> quite slow to boot, too.
>
> Well, XP and Vista aren't what I would call speed demons when it comes
> to booting either....
O.K. I'll take your word for it. I've never booted either.
The latest token Windows that I have is 2000 Pro.
[ ... ]
>>> Here's my desk about two
>>> months ago: <http://thadlabs.com/PIX/Thad_desk.jpg>.
>>> There's 18 computers visible in that photo. My 3B1s and
>>> a bunch of Suns are in my garage and another room along
>>> with my Amigas, a massive C64, and a Convergent Mitiframe.
>>
>> That last one I don't remember hearing about. I do remember a
>> Convergent MiniFrame, but never saw one in the silicon.
>
> I have seen (and actually used) a MiniFrame. I remember hearing about the
> MitiFrame but never saw one.
O.K. And I've now heard more about them from Thad, who has one.
Thad Floryan
> [...]
> Sigh! So does the copper that my T1 comes through. And they
> keep trying to push me onto FIOS -- but won't offer me static IPS,
> and especially a Class-C block of IPs.
Just curious: why do you think you need a block of Class C
IP addresses?
With NAT, a single IP works fine as I've been using for over
a decade.
Last week I read the number of IPv4 addresses "out there"
was around 2.5 billion. Thanks to NAT we haven't had to
migrate to IPv6 and can continue to run "ancient" systems
just fine.
Bill Gunshannon
"DoN. Nichols" <dnic...@d-and-d.com> writes:
> On 2009-01-16, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>> In article <slrngn0af1....@katana.d-and-d.com>,
>> "DoN. Nichols" <dnic...@d-and-d.com> writes:
>>> On 2009-01-15, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>>>> In article <slrngmtmo2....@katana.d-and-d.com>,
>>>> "DoN. Nichols" <dnic...@d-and-d.com> writes:
>
> [ ... ]
>
>>>>> ceilidh!uunet!username@FQDN
>>>>>
>>>>
>>>> I keep trying to convince people that we really need to revive this email
>>>> system. It offers the best and quickest solution to the SPAM problem but
>>>> apparently I am the only one who can see that.
>>>
>>> You know -- I think that would work! (Of course, it would bring
>>> most uses of email to its knees given today's user base. :-)
>>
>> Why? It could, thoretically reduce the amount of email traversing
>> the network by, easily, an order of magnitude as there is at least
>> that much junk. If anything, it would increase the performance.
>> The only shortcoming in the concept of UUCP based Email is eliminated
>> by the use of the INTERNET as the transport medium. Seriously, what
>> would you see as the shortcomings of this idea?
>
> What I was suggesting is that the user base would have to be
> totally re-educated
Why? this is a change to the method used by MTA's, not MUA's. The
users would continue to read email with Firefox, Netscape, Outlook,
even Pine or Elm, whatever their favorite program is.
> -- and a lot of them would fight it tooth and nail.
If done correctly, they would never even now a change occured!
>
> Aside from that -- bang paths are vulnerable to a single machine
> in the path going out of service between the receipt of the incoming
> e-mail and the sending of the reply.
Considering the nature of connectivity over the INTERNET, there should
be no one of consequence with any single path to any other location.
The one thing to remember, is that unlike the days of doing this over
the phone lines there is no additional cost for connecting to any
other location. And you don't have to wait til after midnight when the
rates go down. :-)
>
> But it would sure make it easy to track down the originator of
> spam -- or at least the compromised machine sending it out. :-)
It certainly would. Which is why I mentioned the ability to assign
civil liability. Because no one could send email without going through
a legitimate MTA (no more need for RBL's to try and figure out if that
machine is a dial-up residential connection) the responsibility for
controlling users falls on the service provider. If he wishes to
remain in the email network, he controls his users. If he chooses
not to, he will find himself with no one willing to peer with him.
He is out of business.
>
>>>
>>>>>> And, the 3B2 had no TCPIP. Eventually
>>>>>> Woolongong did one but AT&T never did that I was aware of. That was
>>>>>> a Berkeley thing, not SYS V.
>>>>>
>>>>> The 3B1 used the WillGoWrong TCP/IP package -- with certain
>>>>> problems:
>
> [ ... ]
>
>>>> Do you remember when it was also the TCPIP package on VMS?
>>>
>>> I never ran VMS -- or even accessed a machine running it. I've
>>> got a friend who has been collecting VAXen in all sizes, and does run
>>> VMS at home on one or two of the smaller ones. Not enough power to spin
>>> up the larger ones, let alone not enough room. :-)
>>
>> I dumped all my big disks (RA-series and Fuji Eagles) but VAXen can
>> use smaller, more modern disks. I have a number of VAXStation-3100's
>> that use SCSI and sit on a desktop running VMS quite well.
>
> Sure -- but he had multi-bay machines which he could never run
> as well. :-)
I have some VAX 4000's. I haven'y used them lately, but that is mostly
because of a lack of time and no current project requiring that kind of
resources.
>
>>>
>>>> Of course,
>>>> I think they were also the ones who gave us "Eunice". :-)
>>>
>>> Oh yes -- the only experience with "Eunice" that I have is the
>>> comment from Larry Wall's "configure" script "Oh good! You're not
>>> running Eunice." which told me that it must be pretty bad. :-)
>>
>> Probably the first attempt at what later became known as POSIX. :-)
>> Actually, it worked OK. It was near the resource hog the first Ada
>> compiler was!! :-)
>
> Hmm ... I remember being shocked when I heard that DEC claimed
> POSIX compliance for VMS. :-)
They wrote a POSIX system that ran on top of VMS (exactly the way EUNICE
worked) that met the requirements. As far as I know, they later abandoned
the project.
>
> And, IIRC, the major problem with running unix-inspired things
> on VMS was that process creation on unix was dirt cheap -- just a
> "fork", However, on VMS, it was quite expensive, so a program which was
> quite happy on even an old v7 unix machine would bring VMS to its knees.
Worse than that, while exec() is doable on VMS a real fork() is not.
>
> [ ... ]
>
>>>> Remember where UUNET came from?
>>>
>>> I really never knew -- though I did know that they were local,
>>
>> There used to be a site called "seismo".
>
> That name sounds familiar.
>
>> It grew gradually to become
>> the center of USENET and the non-AT&T UUCPNET. Then one day, someone
>> at the government realized that the machine, in a government site, run
>> by the government, consuming government resources was not doing government
>> business and ordered it to be shut down.
>
> Hmm ... this reminds me of what happened to the system running
> TOPS-20 -- a major repository of open source software. Ah yes -- I
> remember the name now -- simtel20. Many's the time I telneted to that
> from work -- and even some from home eventually.
That was handled much worse. I rbnelieve the the guy who used to run
SIMTEL was actually let go when they shut down the machine. :-)
>
>> This would have been rather
>> a disaster to USENET and a lot of people's email. So, sapce was rented
>> and a new machine set up to take over the job of being the hub of USENET
>> and UUCPNET and UUNET was born. It took on a life of its own and the
>> rest, as they say, is history. I think Rick Adams did nicely by that
>> particular venture. Too bad other people didn't have the same vision
>> he had or things might have developed much better than they have.
>
> Indeed so.
>
>>> and even once visited them (before they moved) to pick up an Exabyte
>>> tape of the sources tree.
>>>
>>> UUNET seems to be dead, but ftp.uu.net still is out there -- it
>>> just hasn't been updated in years.
>>
>> Domain belongs to Verizon. ;-(
>
> Sigh! So does the copper that my T1 comes through. And they
> keep trying to push me onto FIOS -- but won't offer me static IPS, and
> especially a Class-C block of IPs.
Probably because there are none left available. :-) Have to wait
for the arrival of IPv6.
>
> [ ... ]
>
>>>> existed in NEPA. They could not see where anyone would be willing to
>>>> pay money for something like Email or News. :-(
>>>
>>> Interesting. *I* certainly was willing to do so -- even while
>>> working for an Army lab and getting access to Arpanet at the time.
>>
>> Yeah, that was a great example of the shortsightedness of people around
>> here.
>
> Where is "here"?
Northeastern PA. Third or fourth largest metro area in PA.
>
>> I had a similar experience with a local PC company who contracted
>> me to set them up in the ISP business. After many hours of work I showed
>> up one day, not too long before we would have gone live, to find the
>> servers I was building wiped and loaded with Windows. I was told they
>> decided not to pursue that line of business. They gave me a check for
>> what they thought my work was worth and told me goodbye. I could have
>> sued them for breach of contract in order to get the rest of my money
>> but decided it wasn't worth the headache. I have never done any contract
>> work around here since and never would.
>
> Ouch! You should have used machines which would not support
> Windows -- then they couldn't do that. :-)
They were their machines. One of the selling points was the very low
investment to get into the business with a very quick ROI. As an
interesting aside, two ISP's popped up shortly afterwards. One a small
two man operation in a hick part of town and the other a major non-Bell
phone company. Both suffered the same problem. Trying to keep up with
the demand. The two man operation ended out moving into the city as they
quickly exhausted all the available phone bandwidth into their hick town.
The phone company grew to more than 1,000,000 customers in the first year.
At $25.00 a month! Hmmm..... I make that out to be somewhere in the
neighborhood of $300,000,000 gross a year in addition to their already
existing phone revenue. Not bad for something people around here were
telling me there was no business viability and cetainly no liklihood of
profit in!
>
>>>
>>> [ ... ]
>>>
>>>>> It *did* make it easier to break into a system which you had
>>>>> lost the password for. Log in as guest (by default no password), send
>>>>> yourself some e-mail, then click on the mail icon when it popped up, and
>>>>> bang out of the mail program to a root shell. :-)
>>>>
>>>> Yeah, I remember that. Kind of like iPhones that all over the world have
>>>> the same root password. ;-)
>>>
>>> Ouch! I don't have one. Do they even give you access to change
>>> the password?
>>
>> Sure. it's just a linux box in your pocket. Has an sshd available.
>
> Yes -- but through what path? Does it have an ethernet jack?
> Or are you stuck having to expose it to connections over the air?
It's a cellphone. Of course it's exposed over the air. It's also a
WiFi device. Without that it's not an iPhone.
I have quite a few, including some that aren't even DEC.
> There was a
> suite of about four or five boards with it.
It would be interesting to know what they are.
> IIRC, there is a ribbon
> cable bus on the outside edge of the cards to supplement the Q-bus.
Actually, that's probably the cable from a disk controller to the disks
which would be in a differnt box and maybe even a different rack. 8"
floppies or RL02 disks.
>
> Now that I think of it -- it had apparently run Sys-III, and
> I've still got a box of the OS manuals out in /dev/barn02 on top of a
> rack full of stuff.
While not overly thrilled with having yet another version of Unix I
would still be interested in any software you might have. Sadly, if
these are in fact the same thing I have I fear your's are also with
Unix boot PROM's.
>
>>>
>>> Right now -- even if I had lights in that building -- I would
>>> not go out. It is bloody cold out there right now,
>>
>> Not as cold as here. I had pipes wrapped with an electric heat-tape
>> and insulation that were frozen this morning. Got to move south!!
>
> Ouch! Where is "here"? I'm in Northern VA, FWIW.
Scranton/Wilke-sBarre, PA
>
>>> and I doubt that I
>>> could touch anything without launching a static zap. Ask me in the
>>> summertime when the head and humidity will just about kill me before I
>>> dig that far back. :-)
>>>
>>>> If so, which PROMs? They had two. One booted a
>>>> version of Unix (which I have not been able to find) and the other was
>>>> MIKBUG (I think). Mine have the Unix boot PROMs. :-(
>>>
>>> How do I tell? Especially without a card cage to run them in.
>>
>> Well, you can read the label on the PROM if it's still there, otherwise,
>> you have to fire ut up and see what you get for a prompt.
>
> Depends on whether the PROMs just had a label stuck on (which
> may have faded or blown away) or whether they were metal-capped PROMs or
> something with a MelInk stamped identifier. Hmm ... not EPROMs, but
> bipolar single use ones?
Mine have EPROM's. I suppose that was the easiest as they offered more
than one version of firmware.
>
>>>>> And with the 68K's address space, you could put the whole OS
>>>>> including device drivers and device descriptors in ROM (except for
>>>>> something which you were developing) and have plenty of address space
>>>>> left for your applications.
>>>>>
>>>>> Even on a SWTP 6809, with 56 K of RAM, and a lot of OS-9 in 4K
>>>>> of EPROM there was enough room so my wife and I could use it as the same
>>>>> time, as long as I avoided running a big Pascal compile, or used the
>>>>> work processor (Stylo, IIRC.)
>>>>
>>>> OS-9 was rather amazing that way. Imagine the looks on people's faces
>>>> when I demoed three people logged into a Tandy Color Computer with 1 floppy
>>>> and two serial ports (one bit banger and one UART based) and, of course,
>>>> the console. And, I hears it was possible to modify the RS232 PAK so
>>>> that with a MultiPAK interface you could even have two more serial
>>>> ports and support users on all of them. All with a 6809 and 64K of
>>>> memory.
>>>
>>> Yep! And the later CoCos actually had 128K of RAM, and ran
>>> Level-2 OS-9.
>>
>> Yeah, I got that, too. :-)
>
> I never did pick up one of the expanded ones. About that time,
> I was digging into multiple unix boxen, starting with the COSMOS
> CMS16/UNX.
I've got more than enough Unix boxes. As nice as Unix ism some of the
other OSes had a lot to offer as well. Like OS-9 and RSTS.
>
>>> [ ... ]
>>>
>>>>> Try what one friend encountered when bringing a big military
>>>>> surplus transmitter home in the trunk of a car. He and his friend could
>>>>> *barely* lift it -- but the car kept following it up, so getting it clear
>>>>> of the trunk was a major problem. :-)
>>>>
>>>> T-368? :-)
>>>
>>> Probably. I don't remember the model, as I never saw it. I
>>> only heard about it years later.
>>
>> I used to be a radio teletype operator int he Army and remember that
>> one well. I know a number of them have ended out in surplus and went
>> to ham operators. There's a group that meets on 80M that runs AM and
>> I know at least one of these guys is using one. Draws more power than
>> my biggest old iron computer!!
>
> Hmm ... how much power did it put into the final?
Don't remember exactly, several hundred watts. And could run keydown all
day long. We used to send some really long teletype traffic and it never
even flinched.
>
>>>
>>> [ ... ]
>>>
>>>>
>>>> Speaking of SUN 3's..... Know anybody who might be interested in a pair
>>>> of Deskside pedestal model 3's?
>>>
>>> Which ones? The three slot 3/140, or the 12 slot 3/[12]60?
>>> I've got examples of both. And I can't find anyone who wants them.
>>
>> Don't know, have to go look. I may roll them up here later today.
>
> If they roll, it is the 12-slot ones. You could carry the
> three-slot one, and had to put it in a stand to keep it vertical if you
> did not want to lay it down.
These are both on wheels. About 3' high less than 1' wide.
>
>> The
>> only part I really want is the 9-track.
>
> Hmm ... I've got one here -- and nothing running the full VME
> bus still up, so I can't load the interface card for it.
I would assume these are VME. I even have a board floating around here
that adapts VME to the smaller form used in some of the Sparc servers.
(I think they called it 2U or something.)
>
> But I also have a SCSI-Interfaced HP one -- front loading self
> threading machine. Not as much fun to watch as two spinning reels, but
> it works rather well -- or did when I last used it.
I have a SCSI one that I use quite a bit. The other would be usefull
as Pertec shows up as a different device than the SCSI one.
No ouch, They were just SPARCStation-2's.
> Which Ultra was it that you got? I've got Ultra-1
> Ultra-5, Ultra-10, Ultra-60, the SF-280R, several SB-1000s and one
> SB-2000 at present.
Does SUNBlade 100 sound familiar? I think that might be what it is.
>
>>>
>>> Mine I was running SunOs 4.1.4 for a few years after the other
>>> boxes started to get Solaris 2.x in them.
>>
>> I never liked Solaris. I think they should have stayed with SunOS.
>
> Well ... there was a tradeoff. On the older machines, I
> preferred SunOs 4.1.4 (or SunOs 4.1.1_U1 for the Sun-3 machines), but
> for the Ultras, Solaris 10 is quite nice -- especially with zfs in there
> giving me a very nice RAID-5 or two on a couple of systems.
zfs could have been used with a BSD based system. I just never like
SYSV and I worked with it from the very beginning. And RAID is better
handled in hardware, anyway.
>
> The Ultra-5 and Ultra-10 machines are running OpenBSD, so they
> feel more like SunOs 4.1.x, except that you can have 15 partitions
> (exclusive of the whole disk) instead of only seven.
Run BSD at work all the time. Never saw a reason for 15 partitions.
>
> But Solaris 10 seems to be faster on the newer Ultras, and
> OpenBSD has just barely begun to support more than one CPU on the
> UltraSPARC machines.
>
> Oh yes -- I just remembered another couple of machines which I
> forgot to mention in the list. Solbourne S4000 and S4000DX. Soulbourne
> was runing mult-processor on their SPARC systems back when Sun was
> claiming that they had to move to Solaris so they *could* run
> multi-processor. And for quite a while, I was running a SparcStation 10
> with two ROSS double CPU cards in it. Four CPUs -- and to use them I
> had to run SunOs 4.1.4 -- Solaris would not touch them because they did
> not have on-card cache. :-)
Yet another reason why I thought the move to Solaris was a bad thing.
>
> [ ... ]
>
>>>>>> Well, for one thing, MS would likely have never got the stranglehold on
>>>>>> the industry they have.
>>>>>
>>>>> Exactly. They didn't know where to steal an OS for the 68K. :-)
>>>>
>>>> Actually, they already had M68K based desktop systems. Ran Unix.
>>>
>>> And they could not imagine that a user would want unix, I guess. :-)
>>
>> No, had nothing to do with what they could run on it. Had to do with
>> politics and control. Nothing technical in the decision at all.
>
> O.K. Well ... that figures. :-)
>
>>> Or -- they couldn't make it into a closed system the way they
>>> have with Windows. :-)
>>
>> Actually, PC's, with the exception of the the PS/2 and MCA, were never
>> closed.
>
> Right -- the early ones you could get all the data about the
> system you wanted.
>
>> In those days IBM could sell based solely on their name and
>> didn't really worry about cloning. (Aside: I know a local company that
>> paid 3 times as much for SIMMS for their PS/2 from IBM over what it
>> would have cost to get it from Kingston because they insisted it say
>> IBM on the box. The memory they got was Kingston Memory rebadged and
>> shipped in an IBM box.)
>
> But -- later versions of Windows keeps everything possible
> hidden -- especially how to run things like the WinModems (which remind
> me of the floppy drives used in the Apple-II. :-)
I saw winmodems supported under Linux so it couldn't have been all that
much of a secret. The big question was why would you want to give up
CPU time for soemthing that was handled so well in hardware within the
modem itself. I stayed with external modems right up until I shut the
last one down. (Which was last Thursday when I finally pulled the plug
on the departments dial-up IP machine.)
>
>>>>> Now, if the PC had started with the 6809 and OS-9 it would have
>>>>> been a *much* more attractive machine to me. :-)
>>>>
>>>> 6809 was already deadend technology by that point.
>>>
>>> It was more powerful than the 8088 which the PC started with.
>>> And it had as much a claim to being a 16-bit processor as the 8088 did. :-)
>>
>> But suffered fromt he same problem that IBM found with their idea to use
>> the M68K. :-)
>
> Political?
Yes. Came from the same vendor as the M68K.
>
>> A most interesting conversation. I wonder if anyone else is reading and
>> enjoying the reminisce? The most traffic this group has seen in a long
>> time.
>
> I think that some are.
>
> I was away for a couple of days so I could catch up on other
> active newsgroups. "comp.sys.3b1" comes early in the reading sequence,
> and with all the typing I've been doing there, I would get to the other
> newsgroups about time to go to bed. :-)
bill
Bill Gunshannon
Thad Floryan <th...@thadlabs.com> writes:
> On Jan 17, 9:05 pm, "DoN. Nichols" <dnich...@d-and-d.com> wrote:
>> [...]
>> Sigh! So does the copper that my T1 comes through. And they
>> keep trying to push me onto FIOS -- but won't offer me static IPS,
>> and especially a Class-C block of IPs.
>
> Just curious: why do you think you need a block of Class C
> IP addresses?
>
> With NAT, a single IP works fine as I've been using for over
> a decade.
There are a lot of things you can't do with NATed addresses.
>
> Last week I read the number of IPv4 addresses "out there"
> was around 2.5 billion.
There may be that many machines, but the number of addresses is fixed
at 32 bits. :-)
> Thanks to NAT we haven't had to
> migrate to IPv6 and can continue to run "ancient" systems
> just fine.
You have it backwards. because of the delay in going to IPv6 we had
a need for NAT. NAT was never intended as anythng but a temporary
band-aid. IPv6 was ready to go almost a decade ago. My department
actually ran it (yes, we had an assigned IPv6 address block) but due
to lack of interest and the fact that no one else was catching up we
stopped. But it is coming. Slowly but surely.
Thad Floryan
> In article <3c070852-22bc-4612-95fc-bcfc4a6ba...@w39g2000prb.googlegroups.com>,
> Thad Floryan <t...@thadlabs.com> writes:
> [...]
> > With NAT, a single IP works fine as I've been using for over
> > a decade.
>
> There are a lot of things you can't do with NATed addresses.
I'm curious to hear of just one thing that can't be done with
NAT'd addresses.
SSL, VPNs, online gaming, web browsing, email, etc etc all work
just fine. Not just NAT'd but DOUBLE-NAT'd. I had to stick a
second router in my setup to get-around an artificial license
limit with my hardware firewall (SonicWALL).
> > Last week I read the number of IPv4 addresses "out there"
> > was around 2.5 billion.
>
> There may be that many machines, but the number of addresses is fixed
> at 32 bits. :-)
Not machines but global IPv4 addresses. There are probably 4x (or
10 billion) machines "out there".
If we didn't have NAT the address space would have been exhausted
years ago because people/companies wanted Class C blocks even if
they couldn't fully utilize it. Most companies now can work with
just 1-7 "global" IP addresses when they use NAT.
>
> > Thanks to NAT we haven't had to
> > migrate to IPv6 and can continue to run "ancient" systems
> > just fine.
>
> You have it backwards. because of the delay in going to IPv6 we had
> a need for NAT. NAT was never intended as anythng but a temporary
> band-aid. IPv6 was ready to go almost a decade ago. My department
> actually ran it (yes, we had an assigned IPv6 address block) but due
> to lack of interest and the fact that no one else was catching up we
> stopped. But it is coming. Slowly but surely.
"Lack of interest" thanks to NAT. :-)
Don't expect to use a 3B1 on an IPv6 connection. :-)
do...@49.usenet.us.com
> There are a lot of things you can't do with NATed addresses.
I would say "several", not "a lot", since the tally of things that work
just fine is so much larger.
One company where I worked had valid "public" IP addresses on every
machine... thousands of them. Almost none of them could be reached from
outside. Outbound traffic to the internet traveled through NAT/PAT
routers, so the outside world only saw a couple of our thousands of
reserved addresses, wasted out of the IP mapping space.
There are probably a few million PCs with IP addresses of 192.168.0.x
That's the way it should work. They can reach out via NAT to do most
things, but people can't generically reach out to them. A fine situation.
> You have it backwards. because of the delay in going to IPv6 we had
> a need for NAT. NAT was never intended as anythng but a temporary
NAT/PAT is the proper order of things.
Let's see, what random thoughts have I missed posting about in this thread?
Convergent Technologies major product lines:
Intelligent Work Station, Advanced Work Station
Single processor Intel 8088, 8086, proprietary OS, before the IBM PC.
MegaFrame
Multiple processor Intel 80186, proprietary OS.
Add one or more 68010, Unix SVR2, later 68020.
MiniFrame
Single 68010 board, SVR2
stackable 512KB memory cards, 2MB max.
UnixPC, AT&T PC7300, UnixPC, 3B1
Motherboard, some slots, 68010, similar to MiniFrame for some things.
There was a touch screen terminal/telephone at about the same time as the
UnixPC.
MightyFrame
Single board 68020, SVR2/3, expansion slots.
S4040
Single board, one "application" 68040, one "system" 68040.
8800 (?) I forget.
Motorola RISC CPUs, primarily used for CAD in Japan.
Convergent also had the first 80386 32 bit OS on the market in the
Proprietary CTOS and SVR3.
--
Clarence A Dold - Hidden Valley Lake, CA, USA GPS: 38.8,-122.5
DoN. Nichols
> On Jan 17, 9:05 pm, "DoN. Nichols" <dnich...@d-and-d.com> wrote:
>> [...]
>> Sigh! So does the copper that my T1 comes through. And they
>> keep trying to push me onto FIOS -- but won't offer me static IPS,
>> and especially a Class-C block of IPs.
>
> Just curious: why do you think you need a block of Class C
> IP addresses?
Well ... I started without NAT and grew into expecting to run
multiple machines showing up individually on the net. I now have a lot
more machines behind NAT than I have on the outside.
> With NAT, a single IP works fine as I've been using for over
> a decade.
Well ... I have two mail servers and two web servers on the
exposed side of the net, as well as the firewall which is sitting
in front of the rest of the systems.
I would need at least one IP for each of those (I don't share
mail servers and web servers on the same machines), and I also need
another IP for a feed to a friend's net down the street via wireless
bridge. He needs a unique IP outside the firewall for some special
things which he does.
And I used to have a couple of DNS servers out there too.
> Last week I read the number of IPv4 addresses "out there"
> was around 2.5 billion. Thanks to NAT we haven't had to
> migrate to IPv6 and can continue to run "ancient" systems
> just fine.
:-)
Thad Floryan
> On 2009-01-18, Thad Floryan <t...@thadlabs.com> wrote:
> [...]
> > Just curious: why do you think you need a block of Class C
> > IP addresses?
>
> Well ... I started without NAT and grew into expecting to run
> multiple machines showing up individually on the net.
That's how it used to be when the 'Net was small. Heh, around
midyear 2008 I found one of my old ARPA maps, scanned here:
<http://thadlabs.com/FILES/ARPANET_Sept_1982.pdf>
> I now have a lot
> more machines behind NAT than I have on the outside.
I have about 40 machines here at home NAT'd behind one IP.
My mail and Web server is at a colo with another IP address.
> > With NAT, a single IP works fine as I've been using for over
> > a decade.
>
> Well ... I have two mail servers and two web servers on the
> exposed side of the net, as well as the firewall which is sitting
> in front of the rest of the systems.
>
> I would need at least one IP for each of those (I don't share
> mail servers and web servers on the same machines), and I also need
> another IP for a feed to a friend's net down the street via wireless
> bridge. He needs a unique IP outside the firewall for some special
> things which he does.
>
> And I used to have a couple of DNS servers out there too.
Which is fine; an entire Class C block isn't needed. :-)
Thus, there are still some 1.5 billion IPv4 addresses available
(less the 10.*.*.*, 172.[16-31].*.* and 192.168.*.* and the
link-local 169.254.*.* and loopback 127.*.*.*).
DoN. Nichols
How many MTAs automatically generate bang paths these days? And
you would still need a massive database to generate the bang path.
>> -- and a lot of them would fight it tooth and nail.
>
> If done correctly, they would never even now a change occured!
Except for the greater number of messages falling through the
cracks as systems are shut down.
>> Aside from that -- bang paths are vulnerable to a single machine
>> in the path going out of service between the receipt of the incoming
>> e-mail and the sending of the reply.
>
> Considering the nature of connectivity over the INTERNET, there should
> be no one of consequence with any single path to any other location.
What would a bang path look like which used the internet for
connectivity? You still need to know names of systems at each end at
the least. And IIRC, uucp required that there be no two systems with
the same name -- making a naming problem with the number of machines in
use today. After all -- without domain names, it is difficult for a
database to distinguish between systems with the same name to generate
the proper bang path.
The example which I showed above only used uucp to get to uunet.
From there, things went by domain name.
> The one thing to remember, is that unlike the days of doing this over
> the phone lines there is no additional cost for connecting to any
> other location. And you don't have to wait til after midnight when the
> rates go down. :-)
So -- how is it done without domain names between the main trunk
servers at least? *Pure* bang paths required the name of every system
between the origin and the destination.
>> But it would sure make it easy to track down the originator of
>> spam -- or at least the compromised machine sending it out. :-)
>
> It certainly would. Which is why I mentioned the ability to assign
> civil liability. Because no one could send email without going through
> a legitimate MTA (no more need for RBL's to try and figure out if that
> machine is a dial-up residential connection) the responsibility for
> controlling users falls on the service provider. If he wishes to
> remain in the email network, he controls his users. If he chooses
> not to, he will find himself with no one willing to peer with him.
> He is out of business.
If the ISPs would simply block port 25 for all DHCP and dial-up
systems, you would have the same conditions.
[ ... ]
>>> I dumped all my big disks (RA-series and Fuji Eagles) but VAXen can
>>> use smaller, more modern disks. I have a number of VAXStation-3100's
>>> that use SCSI and sit on a desktop running VMS quite well.
>>
>> Sure -- but he had multi-bay machines which he could never run
>> as well. :-)
>
> I have some VAX 4000's. I haven'y used them lately, but that is mostly
> because of a lack of time and no current project requiring that kind of
> resources.
O.K. Did you ever run ultrix on a system? My friend has the
tapes for that acquired from one of the systems he got.
>>
>>>>
>>>>> Of course,
>>>>> I think they were also the ones who gave us "Eunice". :-)
>>>>
>>>> Oh yes -- the only experience with "Eunice" that I have is the
>>>> comment from Larry Wall's "configure" script "Oh good! You're not
>>>> running Eunice." which told me that it must be pretty bad. :-)
>>>
>>> Probably the first attempt at what later became known as POSIX. :-)
>>> Actually, it worked OK. It was near the resource hog the first Ada
>>> compiler was!! :-)
>>
>> Hmm ... I remember being shocked when I heard that DEC claimed
>> POSIX compliance for VMS. :-)
>
> They wrote a POSIX system that ran on top of VMS (exactly the way EUNICE
> worked) that met the requirements. As far as I know, they later abandoned
> the project.
O.K. Before DEC abandoned doing business entirely.
>>
>> And, IIRC, the major problem with running unix-inspired things
>> on VMS was that process creation on unix was dirt cheap -- just a
>> "fork", However, on VMS, it was quite expensive, so a program which was
>> quite happy on even an old v7 unix machine would bring VMS to its knees.
>
> Worse than that, while exec() is doable on VMS a real fork() is not.
Right -- thus the computational cost of emulating fork().
[ ... ]
>>> It grew gradually to become
>>> the center of USENET and the non-AT&T UUCPNET. Then one day, someone
>>> at the government realized that the machine, in a government site, run
>>> by the government, consuming government resources was not doing government
>>> business and ordered it to be shut down.
>>
>> Hmm ... this reminds me of what happened to the system running
>> TOPS-20 -- a major repository of open source software. Ah yes -- I
>> remember the name now -- simtel20. Many's the time I telnetted to that
>> from work -- and even some from home eventually.
>
> That was handled much worse. I rbnelieve the the guy who used to run
> SIMTEL was actually let go when they shut down the machine. :-)
Ouch! Was he let go because of the shutdown, or did he retire,
and nobody else was competent to run the system?
[ ... ]
>>>> UUNET seems to be dead, but ftp.uu.net still is out there -- it
>>>> just hasn't been updated in years.
>>>
>>> Domain belongs to Verizon. ;-(
>>
>> Sigh! So does the copper that my T1 comes through. And they
>> keep trying to push me onto FIOS -- but won't offer me static IPS, and
>> especially a Class-C block of IPs.
>
> Probably because there are none left available. :-) Have to wait
> for the arrival of IPv6.
No -- because they are trying to push it on end users, who will
accept the combination of FIOS for phone, cable, and internet connection
all at the same time. And the box which connects to the internet only
knows how to NAT for a single (dynamic) external IP. I *need* static
IPs, because I run web servers and mail servers.
I probably could talk to their business account division and get
something more to my liking -- without the cable-TV and phone rolled in.
I particularly don't like the FIOS for phone because there is a limited
time that you can lose power before the local electronics run out of
battery charge.
>>
>> [ ... ]
>>
>>>>> existed in NEPA. They could not see where anyone would be willing to
>>>>> pay money for something like Email or News. :-(
>>>>
>>>> Interesting. *I* certainly was willing to do so -- even while
>>>> working for an Army lab and getting access to Arpanet at the time.
>>>
>>> Yeah, that was a great example of the shortsightedness of people around
>>> here.
>>
>> Where is "here"?
>
> Northeastern PA. Third or fourth largest metro area in PA.
O.K. You are not that far away, then. I'm just to the West of
DC in Virginia -- just outside the Beltway. And luckily, I don't have a
need to go into DC for the next few days. :-)
>>> I had a similar experience with a local PC company who contracted
>>> me to set them up in the ISP business. After many hours of work I showed
>>> up one day, not too long before we would have gone live, to find the
>>> servers I was building wiped and loaded with Windows. I was told they
>>> decided not to pursue that line of business. They gave me a check for
>>> what they thought my work was worth and told me goodbye. I could have
>>> sued them for breach of contract in order to get the rest of my money
>>> but decided it wasn't worth the headache. I have never done any contract
>>> work around here since and never would.
>>
>> Ouch! You should have used machines which would not support
>> Windows -- then they couldn't do that. :-)
>
> They were their machines. One of the selling points was the very low
> investment to get into the business with a very quick ROI. As an
> interesting aside, two ISP's popped up shortly afterwards. One a small
> two man operation in a hick part of town and the other a major non-Bell
> phone company. Both suffered the same problem. Trying to keep up with
> the demand. The two man operation ended out moving into the city as they
> quickly exhausted all the available phone bandwidth into their hick town.
> The phone company grew to more than 1,000,000 customers in the first year.
> At $25.00 a month! Hmmm..... I make that out to be somewhere in the
> neighborhood of $300,000,000 gross a year in addition to their already
> existing phone revenue. Not bad for something people around here were
> telling me there was no business viability and cetainly no liklihood of
> profit in!
Hopefully the company which shut down your project is still
kicking themselves now for what they lost. :-)
>>
>>>>
>>>> [ ... ]
>>>>
>>>>>> It *did* make it easier to break into a system which you had
>>>>>> lost the password for. Log in as guest (by default no password), send
>>>>>> yourself some e-mail, then click on the mail icon when it popped up, and
>>>>>> bang out of the mail program to a root shell. :-)
>>>>>
>>>>> Yeah, I remember that. Kind of like iPhones that all over the world have
>>>>> the same root password. ;-)
>>>>
>>>> Ouch! I don't have one. Do they even give you access to change
>>>> the password?
>>>
>>> Sure. it's just a linux box in your pocket. Has an sshd available.
>>
>> Yes -- but through what path? Does it have an ethernet jack?
>> Or are you stuck having to expose it to connections over the air?
>
> It's a cellphone. Of course it's exposed over the air. It's also a
> WiFi device. Without that it's not an iPhone.
But are logins over either allowed by default? If so, then they
should be forced to allow you to change the root password.
>>
>>>> Do they warn you that it should be changed.
>>>
>>> It can't be changed. If you change it, the phone don't work anymore.
>>
>> That is terrible.
>>
>>> Luckily, there is no daemon accepting incoming connections by default,
>>> but many people turn on ssh. And, one never knows what gets done when
>>> you visit one of those whiz-bang web sites. :-)
>>
>> :-)
Given the number of attacks that I see against ssh I would not
want a system which I had not been able to set a good unique password
on.
[ ... ]
>>>>>>> Yeah, I have a couple of QBUS M68K cards that would make great OS9-68K
>>>>>>> machines. And, it's ROMable!!
>>>>>>
>>>>>> I actually have such as set of Qbus cards too.
>>>>>
>>>>> Integrated Solutions?
>>>>
>>>> I don't know. The cards are out in /dev/barn01, with a lot of
>>>> stuff which I would need to move to reach them, and I don't have the
>>>> cage to plug them into.
>>>
>>> You want one? :-) of course, you'll need more QBUS modules if you
>>> actually want to use it.
>>
>> Which -- the backplane? Yes, I would like one.
>
> I have quite a few, including some that aren't even DEC.
>
>> There was a
>> suite of about four or five boards with it.
>
> It would be interesting to know what they are.
>
>> IIRC, there is a ribbon
>> cable bus on the outside edge of the cards to supplement the Q-bus.
>
> Actually, that's probably the cable from a disk controller to the disks
> which would be in a differnt box and maybe even a different rack. 8"
> floppies or RL02 disks.
Nope -- this just connected the several cards together -- and
the multi-connector cable was there with the boards, ending at the last
board on each side. I think that it was either implementing dual-ported
memory, or adding data bus width. What is the maximum address bus
width on Q-bus? Could it even approach the 16 MB of the 68000, let
alone the 4GB of the 68020 and later?
>> Now that I think of it -- it had apparently run Sys-III, and
>> I've still got a box of the OS manuals out in /dev/barn02 on top of a
>> rack full of stuff.
>
> While not overly thrilled with having yet another version of Unix I
> would still be interested in any software you might have.
No software -- just the cards and the manuals. My friend got it
for the Q-bus cage.
> Sadly, if
> these are in fact the same thing I have I fear your's are also with
> Unix boot PROM's.
I suspect so. Any chance of getting sufficient documentation
about the boards so you could write your own boot PROMs?
I know that the COSMOS CMS-16/UNX was very well documented, but
it lived in Intel's MultiBus.
>>
>>>>
>>>> Right now -- even if I had lights in that building -- I would
>>>> not go out. It is bloody cold out there right now,
>>>
>>> Not as cold as here. I had pipes wrapped with an electric heat-tape
>>> and insulation that were frozen this morning. Got to move south!!
>>
>> Ouch! Where is "here"? I'm in Northern VA, FWIW.
>
> Scranton/Wilke-sBarre, PA
And how much colder did it get than here? We saw a low of 7 F
late at night (about 2:00 AM).
Of course, this house was re-built, expanded, and insulation
improved about fifteen years ago.
[ ... ]
>>>>> If so, which PROMs? They had two. One booted a
>>>>> version of Unix (which I have not been able to find) and the other was
>>>>> MIKBUG (I think). Mine have the Unix boot PROMs. :-(
>>>>
>>>> How do I tell? Especially without a card cage to run them in.
>>>
>>> Well, you can read the label on the PROM if it's still there, otherwise,
>>> you have to fire ut up and see what you get for a prompt.
>>
>> Depends on whether the PROMs just had a label stuck on (which
>> may have faded or blown away) or whether they were metal-capped PROMs or
>> something with a MelInk stamped identifier. Hmm ... not EPROMs, but
>> bipolar single use ones?
>
> Mine have EPROM's. I suppose that was the easiest as they offered more
> than one version of firmware.
O.K. I'll see what I have when the weather warms up a bit.
[ ... ]
>>>> Yep! And the later CoCos actually had 128K of RAM, and ran
>>>> Level-2 OS-9.
>>>
>>> Yeah, I got that, too. :-)
>>
>> I never did pick up one of the expanded ones. About that time,
>> I was digging into multiple unix boxen, starting with the COSMOS
>> CMS16/UNX.
>
> I've got more than enough Unix boxes. As nice as Unix ism some of the
> other OSes had a lot to offer as well. Like OS-9 and RSTS.
Yes. Though I have no experience with RSTS. What hardware
would I need to run it? Dual-wide LSI-11, 64 MB of RAM, quad serial
port board, and floppy controller board? Plus the card cage which just
barely hold all of that. I need to hook a power supply to it, and see
what it does.
[ ... ]
>>>>> T-368? :-)
>>>>
>>>> Probably. I don't remember the model, as I never saw it. I
>>>> only heard about it years later.
>>>
>>> I used to be a radio teletype operator int he Army and remember that
>>> one well. I know a number of them have ended out in surplus and went
>>> to ham operators. There's a group that meets on 80M that runs AM and
>>> I know at least one of these guys is using one. Draws more power than
>>> my biggest old iron computer!!
>>
>> Hmm ... how much power did it put into the final?
>
> Don't remember exactly, several hundred watts.
Not a full gallon, then.
> And could run keydown all
> day long. We used to send some really long teletype traffic and it never
> even flinched.
O.K. And that was FSK, so constant broadcast of a pair tones,
flicking back and forth between them.
>>
>>>>
>>>> [ ... ]
>>>>
>>>>>
>>>>> Speaking of SUN 3's..... Know anybody who might be interested in a pair
>>>>> of Deskside pedestal model 3's?
>>>>
>>>> Which ones? The three slot 3/140, or the 12 slot 3/[12]60?
>>>> I've got examples of both. And I can't find anyone who wants them.
>>>
>>> Don't know, have to go look. I may roll them up here later today.
>>
>> If they roll, it is the 12-slot ones. You could carry the
>> three-slot one, and had to put it in a stand to keep it vertical if you
>> did not want to lay it down.
>
> These are both on wheels. About 3' high less than 1' wide.
O.K. The 12-slot ones then. 3/160, 3/260, etc. The 3/180 and
3/280 were rack-mount versions of the same.
And the Sun3 systems would *not* boot from a drive with the
parity enabled, while the SPARC systems *required* it. :-)
>>
>>> The
>>> only part I really want is the 9-track.
>>
>> Hmm ... I've got one here -- and nothing running the full VME
>> bus still up, so I can't load the interface card for it.
>
> I would assume these are VME. I even have a board floating around here
> that adapts VME to the smaller form used in some of the Sparc servers.
> (I think they called it 2U or something.)
>
>>
>> But I also have a SCSI-Interfaced HP one -- front loading self
>> threading machine. Not as much fun to watch as two spinning reels, but
>> it works rather well -- or did when I last used it.
>
> I have a SCSI one that I use quite a bit. The other would be usefull
> as Pertec shows up as a different device than the SCSI one.
Pertec was also a front-loading self threading system, IIRC. I
had one of those connected to my first unix box -- the COSMOS
CMS-16/UNX.
The controller card could move to the VME bus Suns using adaptor
frames to VME.
[ ... ]
>>>> Hmm ... You know that they could be upgraded to SPARC based
>>>> systems with the 4/??? cards -- still use most of the existing cards,
>>>> except for the CPU card itself. And you could replace a lot of big RAM
>>>> boards with a single one full of 4Mx9 SIMMs.
>>>>
>>>> Of course, I think that they could not run anything past perhaps
>>>> Solaris 2.6 -- if that far up the tree. :-)
>>>
>>> This place has abandoned all of that. We used to have a bunch of Sparc
>>> here but I just took the last one (an UltraSparc) home. All the rest
>>> were either given away or trashed. :-(
>>
>> Ouch!
>
> No ouch, They were just SPARCStation-2's.
Oh -- no great loss. :-)
>> Which Ultra was it that you got? I've got Ultra-1
>> Ultra-5, Ultra-10, Ultra-60, the SF-280R, several SB-1000s and one
>> SB-2000 at present.
>
> Does SUNBlade 100 sound familiar? I think that might be what it is.
O.K. One of the ones which used IDE drives. I have one, with
not enough RAM to really make it happy.
>>>> Mine I was running SunOs 4.1.4 for a few years after the other
>>>> boxes started to get Solaris 2.x in them.
>>>
>>> I never liked Solaris. I think they should have stayed with SunOS.
>>
>> Well ... there was a tradeoff. On the older machines, I
>> preferred SunOs 4.1.4 (or SunOs 4.1.1_U1 for the Sun-3 machines), but
>> for the Ultras, Solaris 10 is quite nice -- especially with zfs in there
>> giving me a very nice RAID-5 or two on a couple of systems.
>
> zfs could have been used with a BSD based system.
Yes -- if it was written into the kernel.
> I just never like
> SYSV and I worked with it from the very beginning. And RAID is better
> handled in hardware, anyway.
Hmm ... I remember several hardware RAID systems at work which
were rather fragile -- starting with the Sun one which had three sticks
of ten SCA interface drives each. We had to do corrective work every
time power went down for longer than the UPS could supply, and we
typically had that happen two or three times per year -- including with
snakes comitting suicide in the big transformer farms on post. :-)
The only one which we tried which seemed bulletproof was the one
by DEC.
But I have three A-1000/D-1000 boxes -- one converted to JBOD,
the other two hardware RAID -- and the latter need special management
programs in Solaris which are not upgradable to Solaris 10 (and not
available at all for OpenBSD.
But the zfs seems to be *very* reliable on either a Sun Blade
2000 or a Sun Fire 280R.
And the hardware ones are tailored for a specific range of drive
sizes. With zfs, I started with a set of five 18 GB SCA drives (plus a
hot spare or two), got a tray for fibre channel and a similar number of
36 GB drives, and was able to migrate one drive at a time from the
command line -- and when the last new drive was made active, the
capacity of the array suddenly doubled. Same experience replacing the
36 GB drives with 72 GB drives. It was a clean and smooth transition.
When I get a few more 72 GB FC drives, I'll do the same to the array on
the system which I am typing this on.
>> The Ultra-5 and Ultra-10 machines are running OpenBSD, so they
>> feel more like SunOs 4.1.x, except that you can have 15 partitions
>> (exclusive of the whole disk) instead of only seven.
>
> Run BSD at work all the time. Never saw a reason for 15 partitions.
Well ... perhaps with the new 1 TB and 2.5 TB drives. :-)
And the Ultra-5 and Ultra-10 machines also use IDE drives.
>> But Solaris 10 seems to be faster on the newer Ultras, and
>> OpenBSD has just barely begun to support more than one CPU on the
>> UltraSPARC machines.
>>
>> Oh yes -- I just remembered another couple of machines which I
>> forgot to mention in the list. Solbourne S4000 and S4000DX. Solbourne
>> was runing mult-processor on their SPARC systems back when Sun was
>> claiming that they had to move to Solaris so they *could* run
>> multi-processor. And for quite a while, I was running a SparcStation 10
>> with two ROSS double CPU cards in it. Four CPUs -- and to use them I
>> had to run SunOs 4.1.4 -- Solaris would not touch them because they did
>> not have on-card cache. :-)
>
> Yet another reason why I thought the move to Solaris was a bad thing.
Well ... not necessary for the stated reason, at least.
I think that machines like the Sun Blade [12]000 and Sun Fire
280R are not going to work as well on any available BSD as they do on
Solaris 10.
[ ... ]
>> But -- later versions of Windows keeps everything possible
>> hidden -- especially how to run things like the WinModems (which remind
>> me of the floppy drives used in the Apple-II. :-)
>
> I saw winmodems supported under Linux so it couldn't have been all that
> much of a secret.
Two possible ways:
1) Lots of digging to figure out all the hardware functions in
the cards.
2) Accept a "blob" -- a pre-compiled lump which you have to run
inside a wrapper to adapt it to your OS -- and you have no
access to the source to do a security audit on it. This is why
OpenBSD will not support certain cards, including NVidea,
because they can't do a proper security audit on the source
code. The vendors absolutely *refuse* to release the hardware
documentation so the open-source types can write their own
drivers from scratch. And they require an excessively
restrictive NDA for using the blob.
A lot of linux distributions have signed such NDAs -- and have
been hit by security holes which they could not detect without
the source to analyze. OpenBSD *refuses* blobs.
> The big question was why would you want to give up
> CPU time for soemthing that was handled so well in hardware within the
> modem itself.
I don't -- but if I want to use a modem from a laptop infected
with WinModems, then I may be stuck -- unless I carry a separate modem
as well. (Hmm ... the PCMCIA modem cards -- are they true stand-alone
modems, or are they really WinModems?
> I stayed with external modems right up until I shut the
> last one down. (Which was last Thursday when I finally pulled the plug
> on the departments dial-up IP machine.)
And I've *never* used a WinModem on any hardware which I control.
>>>>>> Now, if the PC had started with the 6809 and OS-9 it would have
>>>>>> been a *much* more attractive machine to me. :-)
>>>>>
>>>>> 6809 was already deadend technology by that point.
>>>>
>>>> It was more powerful than the 8088 which the PC started with.
>>>> And it had as much a claim to being a 16-bit processor as the 8088 did. :-)
>>>
>>> But suffered fromt he same problem that IBM found with their idea to use
>>> the M68K. :-)
>>
>> Political?
>
> Yes. Came from the same vendor as the M68K.
So they did not like the Vendor? Nothing to do with the
hardware?
Thad Floryan
> On 2009-01-18, Bill Gunshannon <billg...@cs.uofs.edu> wrote:
> [...]
> > It certainly would. Which is why I mentioned the ability to assign
> > civil liability. Because no one could send email without going through
> > a legitimate MTA (no more need for RBL's to try and figure out if that
> > machine is a dial-up residential connection) the responsibility for
> > controlling users falls on the service provider. If he wishes to
> > remain in the email network, he controls his users. If he chooses
> > not to, he will find himself with no one willing to peer with him.
> > He is out of business.
>
> If the ISPs would simply block port 25 for all DHCP and dial-up
> systems, you would have the same conditions.
Most ISPs presently block port 25 traffic.
Technically, that's good. Port 25 is for email transfer MTA to MTA.
Port 587 is for email injection to an MTA.
Bill Gunshannon
Thad Floryan <th...@thadlabs.com> writes:
> On Jan 18, 11:12 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
>> In article <3c070852-22bc-4612-95fc-bcfc4a6ba...@w39g2000prb.googlegroups.com>,
>> Thad Floryan <t...@thadlabs.com> writes:
>> [...]
>> > With NAT, a single IP works fine as I've been using for over
>> > a decade.
>>
>> There are a lot of things you can't do with NATed addresses.
>
> I'm curious to hear of just one thing that can't be done with
> NAT'd addresses.
Oh, where to begin!!! Let's see. XDM (pretty much anything X11 related),
some SMB programs running multiple servers that need to be accessed from
outside. Anything that requires the outside site to establish a connection.
>
> SSL, VPNs, online gaming, web browsing, email, etc etc all work
> just fine. Not just NAT'd but DOUBLE-NAT'd. I had to stick a
> second router in my setup to get-around an artificial license
> limit with my hardware firewall (SonicWALL).
Looks like a lot of home use. No one has ever said that homes needed
their own block of IP addresses.
>
>> > Last week I read the number of IPv4 addresses "out there"
>> > was around 2.5 billion.
>>
>> There may be that many machines, but the number of addresses is fixed
>> at 32 bits. :-)
>
> Not machines but global IPv4 addresses. There are probably 4x (or
> 10 billion) machines "out there".
There are 32 bits worth of "global" IPv4 addresses. Actually, not even
that many as a whole bunch are set aside as non-routable for doing stuff
like NAT. Don't confuse 100 machines using non-routable addresses on a
private network with "global" IP addresses. They are hardly global as
all of their connections must originiate behind the NAT firewall.
>
> If we didn't have NAT the address space would have been exhausted
> years ago because people/companies wanted Class C blocks even if
> they couldn't fully utilize it. Most companies now can work with
> just 1-7 "global" IP addresses when they use NAT.
The IPv4 address space was exhausted years ago. Thus the reason why
NAT (and PAT) came into being.
>
>
>>
>> > Thanks to NAT we haven't had to
>> > migrate to IPv6 and can continue to run "ancient" systems
>> > just fine.
>>
>> You have it backwards. because of the delay in going to IPv6 we had
>> a need for NAT. NAT was never intended as anythng but a temporary
>> band-aid. IPv6 was ready to go almost a decade ago. My department
>> actually ran it (yes, we had an assigned IPv6 address block) but due
>> to lack of interest and the fact that no one else was catching up we
>> stopped. But it is coming. Slowly but surely.
>
> "Lack of interest" thanks to NAT. :-)
Nice try, but there has never been a lack of interest.
>
> Don't expect to use a 3B1 on an IPv6 connection. :-)
First, it is trying to accomodate machines like the 3B1, which most people
thought would be long gon by now, that is one of the biggest challenges.
And, considering that in most cases 3B1's are connected to serial links
(there were a lot more 3B1's than ethernet cards for them, I know, I have
6 machines and no ethernet) why would you think they can't play IPv6?
Of course, there is also the IPv4<->IPv6 gateway solution. Think of it
as a higher level NAT. :-)
Bill Gunshannon
do...@49.usenet.us.com writes:
> Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>> There are a lot of things you can't do with NATed addresses.
>
> I would say "several", not "a lot", since the tally of things that work
> just fine is so much larger.
I would disagree. Everything only works in one direction that's 50% right
there. Then when you add in the things that don't work regardless of which
end originates them......
>
> One company where I worked had valid "public" IP addresses on every
> machine... thousands of them. Almost none of them could be reached from
> outside. Outbound traffic to the internet traveled through NAT/PAT
> routers, so the outside world only saw a couple of our thousands of
> reserved addresses, wasted out of the IP mapping space.
And when did they first establish this network? I imagine it is just
like here and it was done back when there really was no option. Changing
an entire network after the fact is a bigger chore than most people even
understand (research some of the white papers done by major companies
who established internal networks using IP addresses pulled out a their
hat who later needed to connect to the INTERNET!!) Remember also, when
a lot of this began there no CIDR or subneted subnets. When I put up
my dial-up IP system for the faculty to use from home I had to do a lot
of smoke and mirrors because the campus network could not deal with the
fact that I had taken a block from our Class B address space (subnet
as 255.255.248.0) and further broken it down into 8 Class C networks.
If it weren't for the fact that IPv6 could be deployed today if people
would just get off their butts, I would be pushing for the turn-in and
re-use of blocks of addresses like we have. At the time I did the
original paperwork and justification for our connection to the INTERNET
a Class B was the only way we could do it. Today, I could put this
place on the net with a handfull of Class C's.
>
> There are probably a few million PCs with IP addresses of 192.168.0.x
> That's the way it should work. They can reach out via NAT to do most
> things, but people can't generically reach out to them. A fine situation.
Unless that PC wants to run X11. :-)
>
>> You have it backwards. because of the delay in going to IPv6 we had
>> a need for NAT. NAT was never intended as anythng but a temporary
>
> NAT/PAT is the proper order of things.
NAT/PAT is a tool. It has a specific purpose. It also has it's shortcomings.
Bill Gunshannon
Yes, but pretty much all of them can (except maybe Exchange! :-) In today's
environment, the database would size would be trivial. 1TB disk : $129.00
The database would not change all that often except for minor additions
and deletions. One could even apply SPF algorithms so that the problem
of the disappearing link (something else that while rather common in the
old days would be very unlikely today) would not eb there either.
>
>>> -- and a lot of them would fight it tooth and nail.
>>
>> If done correctly, they would never even now a change occured!
>
> Except for the greater number of messages falling through the
> cracks as systems are shut down.
Do you mean end-points shutting down? How would that be any differnt than
today? If you mean intermediate links shutting down, just like with News
(which, while using NNTP, still just emulates the same store and forward
model used by the original system) it is unlikely any major player would
have a single connection making routing around failures easy. As a matter
of fact, the reason for only having a few connections under the old UUCP
system no longer exists so having dozens (or even hundreds) of peers is
not really a problem. And once you eliminate the SPAM and other anti-social
practices the system becomes almost maintenance free. Certainly a lot less
maintenance than it takes to run a decent MTA today.
>
>>> Aside from that -- bang paths are vulnerable to a single machine
>>> in the path going out of service between the receipt of the incoming
>>> e-mail and the sending of the reply.
>>
>> Considering the nature of connectivity over the INTERNET, there should
>> be no one of consequence with any single path to any other location.
>
> What would a bang path look like which used the internet for
> connectivity? You still need to know names of systems at each end at
> the least.
Who needs to know? The user? Not hardly. The MTA's need to know and they
do. That's what comp.mail.maps was for. The MTA's use this data to build
a database of destinations. Just like IP, they really only need to know
the next hop to their destination. The users would continue to use the
same addressing they use today.
One of the nice things about this is one could actually handle email
with both systems and phase the new system in over time. The old
SPAM ridden system could remain for those who prefer to not play
but for those of us who would really like to see email become usable
for real communications again we have the new, clean system.
> And IIRC, uucp required that there be no two systems with
> the same name -- making a naming problem with the number of machines in
> use today.
Same thing exists now. There can not be another cs.uofs.edu anywhere
on the INTERNET. So, what's the problem? Or are you assuming we would
still be stuck with single word names of no more than 8 characters?
> After all -- without domain names, it is difficult for a
> database to distinguish between systems with the same name to generate
> the proper bang path.
Why would we not have domain names?
>
> The example which I showed above only used uucp to get to uunet.
> From there, things went by domain name.
Yes, and many of those machines connected by domain name were UUCP
machines. Look at the example I posted earlier of what my address
was.
trotter.usma.edu!bill
There's a three part domain style name used in a bag path. yes, it worked
just fine.
And from the ARPANET dise of the house it was:
bi...@trotter.usma.edu
Both worked just fine. That was 25 years ago. We have gotten a bit better
at doing this stuff since then. :-)
>
>> The one thing to remember, is that unlike the days of doing this over
>> the phone lines there is no additional cost for connecting to any
>> other location. And you don't have to wait til after midnight when the
>> rates go down. :-)
>
> So -- how is it done without domain names between the main trunk
> servers at least? *Pure* bang paths required the name of every system
> between the origin and the destination.
See comments above. The biggest problem I am having selling this idea
seems to be that rather than looking at what it would take to make it
work everyone I talk too just assumes because we did it 25 years ago
and don't do it now it must not be possible. Stop looking for problems
and start looking at solutions.
>
>>> But it would sure make it easy to track down the originator of
>>> spam -- or at least the compromised machine sending it out. :-)
>>
>> It certainly would. Which is why I mentioned the ability to assign
>> civil liability. Because no one could send email without going through
>> a legitimate MTA (no more need for RBL's to try and figure out if that
>> machine is a dial-up residential connection) the responsibility for
>> controlling users falls on the service provider. If he wishes to
>> remain in the email network, he controls his users. If he chooses
>> not to, he will find himself with no one willing to peer with him.
>> He is out of business.
>
> If the ISPs would simply block port 25 for all DHCP and dial-up
> systems, you would have the same conditions.
Yes, but they don't and won't. Because my system requires the exchanging
MTA's to be peers, all the rules are set up ahead of time. You agree to
do certain things in order to be a part of the network. Don;t agree, you
don't get to play. Agree and then violate the agreement, civil liability
for breach of contract. There are really no agreements for ISP's to join
the INTERNET. That's why nothing can be done. They can always fall back
on the argument that there is nothing wrong with what they or their users
are doing. A social problem, requiring a social solution.
>
> [ ... ]
>
>>>> I dumped all my big disks (RA-series and Fuji Eagles) but VAXen can
>>>> use smaller, more modern disks. I have a number of VAXStation-3100's
>>>> that use SCSI and sit on a desktop running VMS quite well.
>>>
>>> Sure -- but he had multi-bay machines which he could never run
>>> as well. :-)
>>
>> I have some VAX 4000's. I haven'y used them lately, but that is mostly
>> because of a lack of time and no current project requiring that kind of
>> resources.
>
> O.K. Did you ever run ultrix on a system? My friend has the
> tapes for that acquired from one of the systems he got.
Not only have, but still do. My systems were used by Frank da Cruz to
build the last couple of binary C-Kermit programs at Columbia.
>
>>>
>>>>>
>>>>>> Of course,
>>>>>> I think they were also the ones who gave us "Eunice". :-)
>>>>>
>>>>> Oh yes -- the only experience with "Eunice" that I have is the
>>>>> comment from Larry Wall's "configure" script "Oh good! You're not
>>>>> running Eunice." which told me that it must be pretty bad. :-)
>>>>
>>>> Probably the first attempt at what later became known as POSIX. :-)
>>>> Actually, it worked OK. It was near the resource hog the first Ada
>>>> compiler was!! :-)
>>>
>>> Hmm ... I remember being shocked when I heard that DEC claimed
>>> POSIX compliance for VMS. :-)
>>
>> They wrote a POSIX system that ran on top of VMS (exactly the way EUNICE
>> worked) that met the requirements. As far as I know, they later abandoned
>> the project.
>
> O.K. Before DEC abandoned doing business entirely.
Well, I meant DEC and theiur successors. The POSIX Kit was around for
a while, but I believe thay have dropped it at this point.
>
>>>
>>> And, IIRC, the major problem with running unix-inspired things
>>> on VMS was that process creation on unix was dirt cheap -- just a
>>> "fork", However, on VMS, it was quite expensive, so a program which was
>>> quite happy on even an old v7 unix machine would bring VMS to its knees.
>>
>> Worse than that, while exec() is doable on VMS a real fork() is not.
>
> Right -- thus the computational cost of emulating fork().
Ummm.... No. Can't be emulated. There is no way under VMS for a new
process to share open file descriptors or devices. The beauty of fork()
is the idea that the fork()ed process is an exact clone of the original.
VMS can not do that.
>
> [ ... ]
>
>>>> It grew gradually to become
>>>> the center of USENET and the non-AT&T UUCPNET. Then one day, someone
>>>> at the government realized that the machine, in a government site, run
>>>> by the government, consuming government resources was not doing government
>>>> business and ordered it to be shut down.
>>>
>>> Hmm ... this reminds me of what happened to the system running
>>> TOPS-20 -- a major repository of open source software. Ah yes -- I
>>> remember the name now -- simtel20. Many's the time I telnetted to that
>>> from work -- and even some from home eventually.
>>
>> That was handled much worse. I rbnelieve the the guy who used to run
>> SIMTEL was actually let go when they shut down the machine. :-)
>
> Ouch! Was he let go because of the shutdown, or did he retire,
> and nobody else was competent to run the system?
He was much too young to retire. When the machine was shut down they no
longer saw a need for his services. Think of it like a library. If you
shut down the library you don't have much need for the librarian.
>
> [ ... ]
>
>>>>> UUNET seems to be dead, but ftp.uu.net still is out there -- it
>>>>> just hasn't been updated in years.
>>>>
>>>> Domain belongs to Verizon. ;-(
>>>
>>> Sigh! So does the copper that my T1 comes through. And they
>>> keep trying to push me onto FIOS -- but won't offer me static IPS, and
>>> especially a Class-C block of IPs.
>>
>> Probably because there are none left available. :-) Have to wait
>> for the arrival of IPv6.
>
> No -- because they are trying to push it on end users, who will
> accept the combination of FIOS for phone, cable, and internet connection
> all at the same time. And the box which connects to the internet only
> knows how to NAT for a single (dynamic) external IP. I *need* static
> IPs, because I run web servers and mail servers.
Then you need a commercial connection and not a residential connection.
I am sure they offer commercial service (FIOS is a purely residential
concept although businesses could probably use the voice and network
part) but you probably don't want to pay the price. Most ISP's I am
aware of specifically prohibit running servers on residential connections.
I know one guy locally who is constantly trying to get around this. I
am surprised the ISP hasn't just terminated his service instead of playing
hide-and-seek with his web server.
>
> I probably could talk to their business account division and get
> something more to my liking -- without the cable-TV and phone rolled in.
> I particularly don't like the FIOS for phone because there is a limited
> time that you can lose power before the local electronics run out of
> battery charge.
I have always been leary of these INTERNET Phone services. If your
service goes out, how do you report it? You have to have some alternate
phone service. Considering how seldom I even use my phone at home my
next location may not have landline phone service at all. I carry one
on my belt, why would I need another?
>
>>>
>>> [ ... ]
>>>
>>>>>> existed in NEPA. They could not see where anyone would be willing to
>>>>>> pay money for something like Email or News. :-(
>>>>>
>>>>> Interesting. *I* certainly was willing to do so -- even while
>>>>> working for an Army lab and getting access to Arpanet at the time.
>>>>
>>>> Yeah, that was a great example of the shortsightedness of people around
>>>> here.
>>>
>>> Where is "here"?
>>
>> Northeastern PA. Third or fourth largest metro area in PA.
>
> O.K. You are not that far away, then. I'm just to the West of
> DC in Virginia -- just outside the Beltway. And luckily, I don't have a
> need to go into DC for the next few days. :-)
I used to work out of Rockville. I know VA pretty well, too. Used to
go to the Pentagon, Arlington and Reston a lot. Many years ago, however.
I doubt it. Idiots never realize their mistakes.
>
>>>
>>>>>
>>>>> [ ... ]
>>>>>
>>>>>>> It *did* make it easier to break into a system which you had
>>>>>>> lost the password for. Log in as guest (by default no password), send
>>>>>>> yourself some e-mail, then click on the mail icon when it popped up, and
>>>>>>> bang out of the mail program to a root shell. :-)
>>>>>>
>>>>>> Yeah, I remember that. Kind of like iPhones that all over the world have
>>>>>> the same root password. ;-)
>>>>>
>>>>> Ouch! I don't have one. Do they even give you access to change
>>>>> the password?
>>>>
>>>> Sure. it's just a linux box in your pocket. Has an sshd available.
>>>
>>> Yes -- but through what path? Does it have an ethernet jack?
>>> Or are you stuck having to expose it to connections over the air?
>>
>> It's a cellphone. Of course it's exposed over the air. It's also a
>> WiFi device. Without that it's not an iPhone.
>
> But are logins over either allowed by default? If so, then they
> should be forced to allow you to change the root password.
BY default? No. But if you decide to start sshd. And then you have
the possibility that someone will come up with a whiz-bang web site
and when you visit it, iy will start sshd for you. :-) They don't
stop you from changing the root password. It's just that there are
apparently things the phone does that require root access and if you
change the password they don't know what it is and so it stops working.
Swell design. :-)
>
>>>
>>>>> Do they warn you that it should be changed.
>>>>
>>>> It can't be changed. If you change it, the phone don't work anymore.
>>>
>>> That is terrible.
>>>
>>>> Luckily, there is no daemon accepting incoming connections by default,
>>>> but many people turn on ssh. And, one never knows what gets done when
>>>> you visit one of those whiz-bang web sites. :-)
>>>
>>> :-)
>
> Given the number of attacks that I see against ssh I would not
> want a system which I had not been able to set a good unique password
> on.
No ssh attack needed. If you start sshd anyone can login using the normal
method.
Not sure what these are but they are not what I have. The VAX used a
ribbon cable as well as the QBUS to connect memory. Some PDP-11's
used PMI Memory which went into certain slots of a particular backplane.
The memory actually came in front of the CPU but I have never had any
PMI memory so I don't know how it worked exactly. Your systems sound
more like a MicroVAX than an M68K.
>
>>> Now that I think of it -- it had apparently run Sys-III, and
>>> I've still got a box of the OS manuals out in /dev/barn02 on top of a
>>> rack full of stuff.
>>
>> While not overly thrilled with having yet another version of Unix I
>> would still be interested in any software you might have.
>
> No software -- just the cards and the manuals. My friend got it
> for the Q-bus cage.
>
>> Sadly, if
>> these are in fact the same thing I have I fear your's are also with
>> Unix boot PROM's.
>
> I suspect so. Any chance of getting sufficient documentation
> about the boards so you could write your own boot PROMs?
Sure, I have all that. But it would be a lot easier if I had the MIKBUG
PROM's as could then just use MIKBUG and download whatever code I was
working on. Kinda like using ODT with either Kermit or VTServer.
>
> I know that the COSMOS CMS-16/UNX was very well documented, but
> it lived in Intel's MultiBus.
>
>>>
>>>>>
>>>>> Right now -- even if I had lights in that building -- I would
>>>>> not go out. It is bloody cold out there right now,
>>>>
>>>> Not as cold as here. I had pipes wrapped with an electric heat-tape
>>>> and insulation that were frozen this morning. Got to move south!!
>>>
>>> Ouch! Where is "here"? I'm in Northern VA, FWIW.
>>
>> Scranton/Wilke-sBarre, PA
>
> And how much colder did it get than here? We saw a low of 7 F
> late at night (about 2:00 AM).
We went below 0. In the very northern rural areas as low as about -17.
>
> Of course, this house was re-built, expanded, and insulation
> improved about fifteen years ago.
And my house is just one big mistake. Kitchen was expanded outside the
foundation with no insulation and no heat where the pipes run. Previous
owner was a real genius. Just another reason why I am not staying here
when I retire. Going where 50 is considered cold. :-)
Isn't the cardcage in a box with a power supply and front panel?
What you need is a real PDP-11 box!! As for RSTS, no hobbyist
program for any of the non-Unix OSes. But, maybe someday.
>
> [ ... ]
>
>>>>>> T-368? :-)
>>>>>
>>>>> Probably. I don't remember the model, as I never saw it. I
>>>>> only heard about it years later.
>>>>
>>>> I used to be a radio teletype operator int he Army and remember that
>>>> one well. I know a number of them have ended out in surplus and went
>>>> to ham operators. There's a group that meets on 80M that runs AM and
>>>> I know at least one of these guys is using one. Draws more power than
>>>> my biggest old iron computer!!
>>>
>>> Hmm ... how much power did it put into the final?
>>
>> Don't remember exactly, several hundred watts.
>
> Not a full gallon, then.
No. It was designed more for key down time than total power. Remember it's
use. In the military you really want to run minimum power cause you make
a great target sitting on top of that mountain advertising you location to
the enemy. :-)
>
>> And could run keydown all
>> day long. We used to send some really long teletype traffic and it never
>> even flinched.
>
> O.K. And that was FSK, so constant broadcast of a pair tones,
> flicking back and forth between them.
>
>>>
>>>>>
>>>>> [ ... ]
>>
>> I have a SCSI one that I use quite a bit. The other would be usefull
>> as Pertec shows up as a different device than the SCSI one.
>
> Pertec was also a front-loading self threading system, IIRC. I
> had one of those connected to my first unix box -- the COSMOS
> CMS-16/UNX.
Pertec is the interface. Two 50 pin connectiors. DEC TS style tapes.
My SCSI looks like a TK50 or TU81+ tape drive but some stuff assumes
TS tapes because of the boot block on it. My SCSI tape is front-loading
self-threading.
> [ ... ]
>
>> Does SUNBlade 100 sound familiar? I think that might be what it is.
>
> O.K. One of the ones which used IDE drives. I have one, with
> not enough RAM to really make it happy.
I thought it just used PC SIMM/DIMM's?
>
>>>>> Mine I was running SunOs 4.1.4 for a few years after the other
>>>>> boxes started to get Solaris 2.x in them.
>>>>
>>>> I never liked Solaris. I think they should have stayed with SunOS.
>>>
>>> Well ... there was a tradeoff. On the older machines, I
>>> preferred SunOs 4.1.4 (or SunOs 4.1.1_U1 for the Sun-3 machines), but
>>> for the Ultras, Solaris 10 is quite nice -- especially with zfs in there
>>> giving me a very nice RAID-5 or two on a couple of systems.
>>
>> zfs could have been used with a BSD based system.
>
> Yes -- if it was written into the kernel.
>
>> I just never like
>> SYSV and I worked with it from the very beginning. And RAID is better
>> handled in hardware, anyway.
>
> Hmm ... I remember several hardware RAID systems at work which
> were rather fragile -- starting with the Sun one which had three sticks
> of ten SCA interface drives each. We had to do corrective work every
> time power went down for longer than the UPS could supply, and we
> typically had that happen two or three times per year -- including with
> snakes comitting suicide in the big transformer farms on post. :-)
I use PCI Adaptec SCSI Raid with no problems. I have also used Promise
IDE RAID cards. All that stuff is usually on the motherboard today. I
also have a StorageWorks cabinet that used to be connected to a VAX
Cluster using CI bus that I will be using via SCSI for otther systems
now that the VAX are all gone. But that's a SAN and a bit more than your
average RAID. :-)
>
> The only one which we tried which seemed bulletproof was the one
> by DEC.
>
> But I have three A-1000/D-1000 boxes -- one converted to JBOD,
> the other two hardware RAID -- and the latter need special management
> programs in Solaris which are not upgradable to Solaris 10 (and not
> available at all for OpenBSD.
>
> But the zfs seems to be *very* reliable on either a Sun Blade
> 2000 or a Sun Fire 280R.
I've used Vinum to get software RAID and it was OK, but recovery seems
to go much better with hardware RAID. At least in my experience.
>>
>> Run BSD at work all the time. Never saw a reason for 15 partitions.
>
> Well ... perhaps with the new 1 TB and 2.5 TB drives. :-)
Nope, still don't see a need for all them partitions. If I have a need
for multiple partitions it is much better to use multiple drives.
> I think that machines like the Sun Blade [12]000 and Sun Fire
> 280R are not going to work as well on any available BSD as they do on
> Solaris 10.
But that is because Sun is able to put stuff into Solaris that BSD
can't. If Sun had stuck to BSD then their version of BSD would
perform just as well and probably better.
>
> [ ... ]
>
>>>>
>>>> But suffered fromt he same problem that IBM found with their idea to use
>>>> the M68K. :-)
>>>
>>> Political?
>>
>> Yes. Came from the same vendor as the M68K.
>
> So they did not like the Vendor? Nothing to do with the
> hardware?
It was not a matter of like or dislike as much as a matter of control or
not control.
Thad Floryan
> In article <dc3c33cd-abd3-4965-aab8-ba8b967f9...@n33g2000pri.googlegroups.com>,> [...]
> There are 32 bits worth of "global" IPv4 addresses. Actually, not even
> that many as a whole bunch are set aside as non-routable for doing stuff
> like NAT. Don't confuse 100 machines using non-routable addresses on a
> private network with "global" IP addresses. They are hardly global as
> all of their connections must originiate behind the NAT firewall.
I know how NAT/PAT work. Who confused internal LAN IPs with global
WAN IP addresses?
> > If we didn't have NAT the address space would have been exhausted
> > years ago because people/companies wanted Class C blocks even if
> > they couldn't fully utilize it. Most companies now can work with
> > just 1-7 "global" IP addresses when they use NAT.
>
> The IPv4 address space was exhausted years ago. Thus the reason why
> NAT (and PAT) came into being.
And why we presently have approximately 1.5 billion available
IPv4 global IP addresses.
For those who might wish further info on this subject:
<http://www.cisco.com/application/pdf/paws/6450/nat-cisco.pdf>
<http://www.dslreports.com/faq/13449>
<http://www.techweb.com/encyclopedia/defineterm.jhtml?term=Nat>
<http://en.wikipedia.org/wiki/Network_address_translation>
<http://www.webopedia.com/DidYouKnow/Computer_Science/2006/
NAT_and_PAT.asp>
Thad Floryan
> [...]
> Same thing exists now. There can not be another cs.uofs.edu anywhere
> on the INTERNET. So, what's the problem? Or are you assuming we would
> still be stuck with single word names of no more than 8 characters?
8?
Perhaps you've forgotten "snorklewacker" was a valid host in
the UUCP maps.
:-)
DoN. Nichols
> On Jan 18, 5:23 pm, "DoN. Nichols" <dnich...@d-and-d.com> wrote:
>> On 2009-01-18, Thad Floryan <t...@thadlabs.com> wrote:
>> [...]
>> > Just curious: why do you think you need a block of Class C
>> > IP addresses?
>>
>> Well ... I started without NAT and grew into expecting to run
>> multiple machines showing up individually on the net.
>
> That's how it used to be when the 'Net was small. Heh, around
> midyear 2008 I found one of my old ARPA maps, scanned here:
>
><http://thadlabs.com/FILES/ARPANET_Sept_1982.pdf>
>
>> I now have a lot
>> more machines behind NAT than I have on the outside.
>
> I have about 40 machines here at home NAT'd behind one IP.
I can't afford to run that many at one time these days, though
if I fired up everything, I could probably reach that point.
> My mail and Web server is at a colo with another IP address.
That makes a difference, of course. You are still using the IP
address, just not locally.
>> > With NAT, a single IP works fine as I've been using for over
>> > a decade.
>>
>> Well ... I have two mail servers and two web servers on the
>> exposed side of the net, as well as the firewall which is sitting
>> in front of the rest of the systems.
>>
>> I would need at least one IP for each of those (I don't share
>> mail servers and web servers on the same machines), and I also need
>> another IP for a feed to a friend's net down the street via wireless
>> bridge. He needs a unique IP outside the firewall for some special
>> things which he does.
>>
>> And I used to have a couple of DNS servers out there too.
>
> Which is fine; an entire Class C block isn't needed. :-)
Agreed -- but when I first got my net feed, the choices were a
single IP or a Class-C, and I had nothing to handle NATing at the time.
But FIOS is still not offering anything other than a single
*dynamic* IP, which is not satisfactory for running either two web
servers or two mail servers plus a NAT for things inside.
> Thus, there are still some 1.5 billion IPv4 addresses available
> (less the 10.*.*.*, 172.[16-31].*.* and 192.168.*.* and the
> link-local 169.254.*.* and loopback 127.*.*.*).
And my internal ones are in the 10.*.*.* region.
DoN. Nichols
>> On 2009-01-18, Bill Gunshannon <billg...@cs.uofs.edu> wrote:
>> [...]
>> > It certainly would. Which is why I mentioned the ability to assign
>> > civil liability. Because no one could send email without going through
>> > a legitimate MTA (no more need for RBL's to try and figure out if that
>> > machine is a dial-up residential connection) the responsibility for
>> > controlling users falls on the service provider. If he wishes to
>> > remain in the email network, he controls his users. If he chooses
>> > not to, he will find himself with no one willing to peer with him.
>> > He is out of business.
>>
>> If the ISPs would simply block port 25 for all DHCP and dial-up
>> systems, you would have the same conditions.
>
> Most ISPs presently block port 25 traffic.
Not the largest ones. Verizon, road runner, comcast, and a
bunch of others let connections on port 25 out, as I can prove based on
the delivery attempts here from systems which reverse-DNS as dhcp
allocated systems with no private DNS entries.
> Technically, that's good. Port 25 is for email transfer MTA to MTA.
Agreed! That is why I wish that more would block port 25 for
DHCP allocated IPs.
> Port 587 is for email injection to an MTA.
But I run my own mail servers with static IPs, and with reverse
DNS records.
DoN. Nichols
I not $127.00 for a SCSI or Fibre Channel version. :-(
And there are still people who have dialup connections, and the
download time for the updated maps would be a killer for them.
> The database would not change all that often except for minor additions
> and deletions.
How many end users change ISPs in the US per day? How about in
the world. A bang path has to find its way to the user's machine, or
the user's ISP's mail server. Since I run my own mail servers, I
consider that it has to reach *my* machines.
> One could even apply SPF algorithms so that the problem
> of the disappearing link (something else that while rather common in the
> old days would be very unlikely today) would not eb there either.
How do you intend to make this work? What does your bang-path
look like as you plan the new system? How is a user to select an end
system if the system names are duplicated. (And I say *system* names,
not domain names. The FQDN replaced bang paths, so if you are going
back to bang paths, it would seem that you are getting rid of the FQDN.
>>
>>>> -- and a lot of them would fight it tooth and nail.
>>>
>>> If done correctly, they would never even now a change occured!
>>
>> Except for the greater number of messages falling through the
>> cracks as systems are shut down.
>
> Do you mean end-points shutting down? How would that be any differnt than
> today? If you mean intermediate links shutting down, just like with News
> (which, while using NNTP, still just emulates the same store and forward
> model used by the original system)
Uucp mail (via bang paths) was to store and forward to a single
system closer to the destination.
News (also via bang paths) was to store and broadcast to all
other known news server connections.
If one system goes down, *news* gets there via other paths, but
email bang paths die at the dead system, because they are not broadcast
to all known connections. You don't *want* something addressed to an
individual to be broadcast all over the world. :-)
> it is unlikely any major player would
> have a single connection making routing around failures easy.
You're assuming that there will only be major players in the
game. Bang paths often went through a number of other small systems
before they got to a backbone system. At first, my outgoing email was:
dnichols@ceilidh!beartrack!uunet!username@FQDN
and that was only because uunet was really using the FQDN and smtp to
move e-mail around. "beartrack" was owned by a friend, and he forwarded
my outgoing and incoming e-mail to/from uunet, who then converted it to
FQDN format.
> As a matter
> of fact, the reason for only having a few connections under the old UUCP
> system no longer exists so having dozens (or even hundreds) of peers is
> not really a problem.
You are assuming that the current FQDN system is kept alive so
connections to other systems is cheap. But how is this bang-path then?
And do *you* really want to broadcast your e-mail to every
machine in the world -- making it easy for projects like "carnivore" to
study everything, and making the load on small severs rather
overwhelming. Usenet is intended for the world, so broadcast
distribution makes sense. Email is not.
> And once you eliminate the SPAM and other anti-social
> practices the system becomes almost maintenance free. Certainly a lot less
> maintenance than it takes to run a decent MTA today.
IIRC, bang paths took a lot of maintenance. Again -- are you
planning to continue to use the DNS which supplanted bang paths, and
just turn off port 25 (smtp) and replace it with something else? If so,
how do you keep the spamers from figuring out how to manipulate *that*
system as well?
>>
>>>> Aside from that -- bang paths are vulnerable to a single machine
>>>> in the path going out of service between the receipt of the incoming
>>>> e-mail and the sending of the reply.
>>>
>>> Considering the nature of connectivity over the INTERNET, there should
>>> be no one of consequence with any single path to any other location.
>>
>> What would a bang path look like which used the internet for
>> connectivity? You still need to know names of systems at each end at
>> the least.
>
> Who needs to know? The user? Not hardly. The MTA's need to know and they
> do. That's what comp.mail.maps was for. The MTA's use this data to build
> a database of destinations. Just like IP, they really only need to know
> the next hop to their destination. The users would continue to use the
> same addressing they use today.
But an outgoing bang path needed the full list of machines on
the way. *This* is what would make tracking spam back easier. If you
don't have that, you just have a somewhat slower name lookup process
with a greater chance of errors.
> One of the nice things about this is one could actually handle email
> with both systems and phase the new system in over time. The old
> SPAM ridden system could remain for those who prefer to not play
> but for those of us who would really like to see email become usable
> for real communications again we have the new, clean system.
>
>> And IIRC, uucp required that there be no two systems with
>> the same name -- making a naming problem with the number of machines in
>> use today.
>
> Same thing exists now. There can not be another cs.uofs.edu anywhere
> on the INTERNET. So, what's the problem? Or are you assuming we would
> still be stuck with single word names of no more than 8 characters?
You have a FQDN there, not just a system name. Your system name
is 'cs', and how many 'cs' machines are there at colleges around the
country? *That* is the duplication which had to be avoided for
comp.mail.maps to work.
And think of the number of PCs running Windows which get a
default name which matches every other system from the same CD-ROM
distribution.
>> After all -- without domain names, it is difficult for a
>> database to distinguish between systems with the same name to generate
>> the proper bang path.
>
> Why would we not have domain names?
Because they are not used in normal bang paths.
Again I ask -- just what would your addressing look like with
the revived bang path which you are advocating? Until I see that, I
can't see how it would work in today's environment.
>> The example which I showed above only used uucp to get to uunet.
>> From there, things went by domain name.
>
> Yes, and many of those machines connected by domain name were UUCP
> machines. Look at the example I posted earlier of what my address
> was.
> trotter.usma.edu!bill
>
> There's a three part domain style name used in a bag path. yes, it worked
> just fine.
But it required a system which understood FQDNs.
> And from the ARPANET dise of the house it was:
> bi...@trotter.usma.edu
>
> Both worked just fine. That was 25 years ago. We have gotten a bit better
> at doing this stuff since then. :-)
You are talking about the merge between bang paths and FQDNs,
not pure bang paths. And I fail to see what benefit that would offer,
as it would not keep a track of the machines a spam passed through on
the way to you.
>>> The one thing to remember, is that unlike the days of doing this over
>>> the phone lines there is no additional cost for connecting to any
>>> other location. And you don't have to wait til after midnight when the
>>> rates go down. :-)
>>
>> So -- how is it done without domain names between the main trunk
>> servers at least? *Pure* bang paths required the name of every system
>> between the origin and the destination.
>
> See comments above. The biggest problem I am having selling this idea
> seems to be that rather than looking at what it would take to make it
> work everyone I talk too just assumes because we did it 25 years ago
> and don't do it now it must not be possible. Stop looking for problems
> and start looking at solutions.
While I'm having difficulty seeing how it would be implemented
with today's systems -- and what it really would do better?
And uucp needs the delivering systems to be given a login
(restricted to uucp only, but still a path into your or my system).
>>
>>>> But it would sure make it easy to track down the originator of
>>>> spam -- or at least the compromised machine sending it out. :-)
>>>
>>> It certainly would. Which is why I mentioned the ability to assign
>>> civil liability. Because no one could send email without going through
>>> a legitimate MTA (no more need for RBL's to try and figure out if that
>>> machine is a dial-up residential connection) the responsibility for
>>> controlling users falls on the service provider. If he wishes to
>>> remain in the email network, he controls his users. If he chooses
>>> not to, he will find himself with no one willing to peer with him.
>>> He is out of business.
>>
>> If the ISPs would simply block port 25 for all DHCP and dial-up
>> systems, you would have the same conditions.
>
> Yes, but they don't and won't.
You and Thad seem to disagree here.
I agree that too many don't.
> Because my system requires the exchanging
> MTA's to be peers, all the rules are set up ahead of time. You agree to
> do certain things in order to be a part of the network. Don;t agree, you
> don't get to play. Agree and then violate the agreement, civil liability
> for breach of contract. There are really no agreements for ISP's to join
> the INTERNET. That's why nothing can be done. They can always fall back
> on the argument that there is nothing wrong with what they or their users
> are doing. A social problem, requiring a social solution.
Given that some of the largest ISPs are offenders (like Verizon,
Comcats, road-runner, and others), how long do you think it would take
for them to claim "But you *can't* shut us down and deprive all of these
hundreds of thousands of people of their e-mail." Just the problem we
have with the current system.
[ ... ]
>> O.K. Did you ever run ultrix on a system? My friend has the
>> tapes for that acquired from one of the systems he got.
>
> Not only have, but still do. My systems were used by Frank da Cruz to
> build the last couple of binary C-Kermit programs at Columbia.
O.K.
[ ... ]
>>>> Hmm ... I remember being shocked when I heard that DEC claimed
>>>> POSIX compliance for VMS. :-)
>>>
>>> They wrote a POSIX system that ran on top of VMS (exactly the way EUNICE
>>> worked) that met the requirements. As far as I know, they later abandoned
>>> the project.
>>
>> O.K. Before DEC abandoned doing business entirely.
>
> Well, I meant DEC and theiur successors. The POSIX Kit was around for
> a while, but I believe thay have dropped it at this point.
Is there someone keeping VMS going? Someone making the hardware
for it?
>>
>>>>
>>>> And, IIRC, the major problem with running unix-inspired things
>>>> on VMS was that process creation on unix was dirt cheap -- just a
>>>> "fork", However, on VMS, it was quite expensive, so a program which was
>>>> quite happy on even an old v7 unix machine would bring VMS to its knees.
>>>
>>> Worse than that, while exec() is doable on VMS a real fork() is not.
>>
>> Right -- thus the computational cost of emulating fork().
>
> Ummm.... No. Can't be emulated. There is no way under VMS for a new
> process to share open file descriptors or devices. The beauty of fork()
> is the idea that the fork()ed process is an exact clone of the original.
> VMS can not do that.
Emulated with a very complex (and CPU cycle hungry) wrapper to
emulate the shared open file descriptors.
>>
>> [ ... ]
>>
>>>>> It grew gradually to become
>>>>> the center of USENET and the non-AT&T UUCPNET. Then one day, someone
>>>>> at the government realized that the machine, in a government site, run
>>>>> by the government, consuming government resources was not doing government
>>>>> business and ordered it to be shut down.
>>>>
>>>> Hmm ... this reminds me of what happened to the system running
>>>> TOPS-20 -- a major repository of open source software. Ah yes -- I
>>>> remember the name now -- simtel20. Many's the time I telnetted to that
>>>> from work -- and even some from home eventually.
>>>
>>> That was handled much worse. I rbnelieve the the guy who used to run
>>> SIMTEL was actually let go when they shut down the machine. :-)
>>
>> Ouch! Was he let go because of the shutdown, or did he retire,
>> and nobody else was competent to run the system?
>
> He was much too young to retire. When the machine was shut down they no
> longer saw a need for his services. Think of it like a library. If you
> shut down the library you don't have much need for the librarian.
O.K. I don't have to like it.
>>
>> [ ... ]
>>
>>>>>> UUNET seems to be dead, but ftp.uu.net still is out there -- it
>>>>>> just hasn't been updated in years.
>>>>>
>>>>> Domain belongs to Verizon. ;-(
>>>>
>>>> Sigh! So does the copper that my T1 comes through. And they
>>>> keep trying to push me onto FIOS -- but won't offer me static IPS, and
>>>> especially a Class-C block of IPs.
>>>
>>> Probably because there are none left available. :-) Have to wait
>>> for the arrival of IPv6.
>>
>> No -- because they are trying to push it on end users, who will
>> accept the combination of FIOS for phone, cable, and internet connection
>> all at the same time. And the box which connects to the internet only
>> knows how to NAT for a single (dynamic) external IP. I *need* static
>> IPs, because I run web servers and mail servers.
>
> Then you need a commercial connection and not a residential connection.
> I am sure they offer commercial service (FIOS is a purely residential
> concept although businesses could probably use the voice and network
> part) but you probably don't want to pay the price.
I'm already paying the price for a T1 connection. The question
is how much more or less would they ask for the same?
But I keep getting calls from salesmen wanting to sell me a
*residential* FIOS feed.
> Most ISP's I am
> aware of specifically prohibit running servers on residential connections.
I have a business account. I have static IPs, and run both mail
and web servers on them.
> I know one guy locally who is constantly trying to get around this. I
> am surprised the ISP hasn't just terminated his service instead of playing
> hide-and-seek with his web server.
Why not simply buy a business account as I did.
>> I probably could talk to their business account division and get
>> something more to my liking -- without the cable-TV and phone rolled in.
>> I particularly don't like the FIOS for phone because there is a limited
>> time that you can lose power before the local electronics run out of
>> battery charge.
>
> I have always been leary of these INTERNET Phone services. If your
> service goes out, how do you report it? You have to have some alternate
> phone service. Considering how seldom I even use my phone at home my
> next location may not have landline phone service at all. I carry one
> on my belt, why would I need another?
This is not exactly an internet phone service. It is a fiber
optics feed which provides phone, cable, and internet through the same
fiber.
[ ... ]
>>>>> Yeah, that was a great example of the shortsightedness of people around
>>>>> here.
>>>>
>>>> Where is "here"?
>>>
>>> Northeastern PA. Third or fourth largest metro area in PA.
>>
>> O.K. You are not that far away, then. I'm just to the West of
>> DC in Virginia -- just outside the Beltway. And luckily, I don't have a
>> need to go into DC for the next few days. :-)
>
> I used to work out of Rockville. I know VA pretty well, too. Used to
> go to the Pentagon, Arlington and Reston a lot. Many years ago, however.
Today would have been a bad time for that. Any traffic between
VA and DC was shut down for most of the day. :-)
[ ... ]
>> Hopefully the company which shut down your project is still
>> kicking themselves now for what they lost. :-)
>
> I doubt it. Idiots never realize their mistakes.
[ ... ]
>>>>> Sure. it's just a linux box in your pocket. Has an sshd available.
>>>>
>>>> Yes -- but through what path? Does it have an ethernet jack?
>>>> Or are you stuck having to expose it to connections over the air?
>>>
>>> It's a cellphone. Of course it's exposed over the air. It's also a
>>> WiFi device. Without that it's not an iPhone.
>>
>> But are logins over either allowed by default? If so, then they
>> should be forced to allow you to change the root password.
>
> BY default? No. But if you decide to start sshd. And then you have
> the possibility that someone will come up with a whiz-bang web site
> and when you visit it, iy will start sshd for you. :-)
Ouch!
> They don't
> stop you from changing the root password. It's just that there are
> apparently things the phone does that require root access and if you
> change the password they don't know what it is and so it stops working.
> Swell design. :-)
It needs sudo activated to give root permission to their account
for only those things.
>>
>>>>
>>>>>> Do they warn you that it should be changed.
>>>>>
>>>>> It can't be changed. If you change it, the phone don't work anymore.
>>>>
>>>> That is terrible.
>>>>
>>>>> Luckily, there is no daemon accepting incoming connections by default,
>>>>> but many people turn on ssh. And, one never knows what gets done when
>>>>> you visit one of those whiz-bang web sites. :-)
>>>>
>>>> :-)
>>
>> Given the number of attacks that I see against ssh I would not
>> want a system which I had not been able to set a good unique password
>> on.
>
> No ssh attack needed. If you start sshd anyone can login using the normal
> method.
Well ... the typical attacks start with attempting to log in to
common accounts -- I think trying for ones with no password. Then they
repeat with various passwords until the firewall slams the door on the
protected net or I add them to my block list on the other (exposed)
systems.
[ ... ]
>>>>>>> Integrated Solutions?
>>>>>>
>>>>>> I don't know. The cards are out in /dev/barn01, with a lot of
>>>>>> stuff which I would need to move to reach them, and I don't have the
>>>>>> cage to plug them into.
>>>>>
>>>>> You want one? :-) of course, you'll need more QBUS modules if you
>>>>> actually want to use it.
>>>>
>>>> Which -- the backplane? Yes, I would like one.
>>>
>>> I have quite a few, including some that aren't even DEC.
>>>
>>>> There was a
>>>> suite of about four or five boards with it.
>>>
>>> It would be interesting to know what they are.
>>>
>>>> IIRC, there is a ribbon
>>>> cable bus on the outside edge of the cards to supplement the Q-bus.
>>>
>>> Actually, that's probably the cable from a disk controller to the disks
>>> which would be in a differnt box and maybe even a different rack. 8"
>>> floppies or RL02 disks.
>>
>> Nope -- this just connected the several cards together -- and
>> the multi-connector cable was there with the boards, ending at the last
>> board on each side. I think that it was either implementing dual-ported
>> memory, or adding data bus width. What is the maximum address bus
>> width on Q-bus? Could it even approach the 16 MB of the 68000, let
>> alone the 4GB of the 68020 and later?
>
> Not sure what these are but they are not what I have. The VAX used a
> ribbon cable as well as the QBUS to connect memory.
Was the ribbon cable on the edge opposite the bus connectors?
> Some PDP-11's
> used PMI Memory which went into certain slots of a particular backplane.
> The memory actually came in front of the CPU but I have never had any
> PMI memory so I don't know how it worked exactly. Your systems sound
> more like a MicroVAX than an M68K.
Intersting. But it is certainly a M68K CPU. I forget whether
it is plain vanilla 68000 or 68010, or one of the smaller square chips
from later. Still too cold to go out and get the boards.
[ ... ]
>> No software -- just the cards and the manuals. My friend got it
>> for the Q-bus cage.
>>
>>> Sadly, if
>>> these are in fact the same thing I have I fear your's are also with
>>> Unix boot PROM's.
>>
>> I suspect so. Any chance of getting sufficient documentation
>> about the boards so you could write your own boot PROMs?
>
> Sure, I have all that. But it would be a lot easier if I had the MIKBUG
> PROM's as could then just use MIKBUG and download whatever code I was
> working on. Kinda like using ODT with either Kermit or VTServer.
Hmm ... I never experience MIKBUG for the 68K systems, just for
the 6800. (Not even for the 6809.)
[ ... ]
>>>> Ouch! Where is "here"? I'm in Northern VA, FWIW.
>>>
>>> Scranton/Wilke-sBarre, PA
>>
>> And how much colder did it get than here? We saw a low of 7 F
>> late at night (about 2:00 AM).
>
> We went below 0. In the very northern rural areas as low as about -17.
Ouch!
>> Of course, this house was re-built, expanded, and insulation
>> improved about fifteen years ago.
>
> And my house is just one big mistake. Kitchen was expanded outside the
> foundation with no insulation and no heat where the pipes run. Previous
> owner was a real genius. Just another reason why I am not staying here
> when I retire. Going where 50 is considered cold. :-)
I can understand that. I'm glad to already be retired, but
there is too much to move to go to someplace like South Texas, where I
grew up.
[ ... ]
>>>> Depends on whether the PROMs just had a label stuck on (which
>>>> may have faded or blown away) or whether they were metal-capped PROMs or
>>>> something with a MelInk stamped identifier. Hmm ... not EPROMs, but
>>>> bipolar single use ones?
>>>
>>> Mine have EPROM's. I suppose that was the easiest as they offered more
>>> than one version of firmware.
>>
>> O.K. I'll see what I have when the weather warms up a bit.
[ ... ]
>>> I've got more than enough Unix boxes. As nice as Unix ism some of the
>>> other OSes had a lot to offer as well. Like OS-9 and RSTS.
>>
>> Yes. Though I have no experience with RSTS. What hardware
>> would I need to run it? Dual-wide LSI-11, 64 MB of RAM, quad serial
>> port board, and floppy controller board? Plus the card cage which just
>> barely hold all of that. I need to hook a power supply to it, and see
>> what it does.
>
> Isn't the cardcage in a box with a power supply and front panel?
Nope. Just the bare cardcage with four slots (IIRC) and a
backplane. Some of the cards are single-wide and some double wide, with
the CPU being double wide. Maybe it is only three slots. One 64K
memory card, one quad serial port card, and one floppy controller card.
> What you need is a real PDP-11 box!!
Too big, too heavy. :-) And IIRC, DEC favored linear regulated
power supplies instead of switching supplies, which makes it even
heavier. :-)
> As for RSTS, no hobbyist
> program for any of the non-Unix OSes. But, maybe someday.
O.K. What OS is there likely to be for the LSI-11 then?
[ ... ]
>>>> Hmm ... how much power did it put into the final?
>>>
>>> Don't remember exactly, several hundred watts.
>>
>> Not a full gallon, then.
>
> No. It was designed more for key down time than total power. Remember it's
> use. In the military you really want to run minimum power cause you make
> a great target sitting on top of that mountain advertising you location to
> the enemy. :-)
O.K. And no multiplexing the antenna farm to make it appear to
jump around the countryside. :-)
[ ... ]
>>>
>>> I have a SCSI one that I use quite a bit. The other would be usefull
>>> as Pertec shows up as a different device than the SCSI one.
>>
>> Pertec was also a front-loading self threading system, IIRC. I
>> had one of those connected to my first unix box -- the COSMOS
>> CMS-16/UNX.
>
> Pertec is the interface.
Pertec was probably also once a maker, just as the "centronics"
interface was originally the 36-pin parallel interface developed by
Centronix, the printer maker. (And later, people started callign the
50-pin interface for SCSI from the same line of connectors "cenronix",
thus getting it even farther from the origins.)
> Two 50 pin connectiors. DEC TS style tapes.
> My SCSI looks like a TK50 or TU81+ tape drive but some stuff assumes
> TS tapes because of the boot block on it. My SCSI tape is front-loading
> self-threading.
Two 50-pin edge connectors from my first one (Ciprico was it)
front loading self threading black for the COSMOS CMS-16/UNX. I've got
another of those drives which uses the DD-50 connectors, but presumably
the same interface.
>> [ ... ]
>>
>>> Does SUNBlade 100 sound familiar? I think that might be what it is.
>>
>> O.K. One of the ones which used IDE drives. I have one, with
>> not enough RAM to really make it happy.
>
> I thought it just used PC SIMM/DIMM's?
Explicitly (From the Sun FEH):
370-4149 128 MB 3.3 ECC 10nS SDRAM DIMM
370-4140 256 MB 3.3 ECC 10nS SDRAM DIMM
370-4151 512 MB 3.3 ECC 10nS SDRAM DIMM
All 168-pin with one center key, and one key to the left. From
discussions on comp.sys.sun.hardware, they are uncommon ones.
Depending on the CPU clock speed, you can put a maximum of
either 512MB or 1GB per DIMM, but they don't mention a part number for
the 1GB version.
[ ... ]
>>> I just never like
>>> SYSV and I worked with it from the very beginning. And RAID is better
>>> handled in hardware, anyway.
>>
>> Hmm ... I remember several hardware RAID systems at work which
>> were rather fragile -- starting with the Sun one which had three sticks
>> of ten SCA interface drives each. We had to do corrective work every
>> time power went down for longer than the UPS could supply, and we
>> typically had that happen two or three times per year -- including with
>> snakes comitting suicide in the big transformer farms on post. :-)
>
> I use PCI Adaptec SCSI Raid with no problems.
With which OS? IIRC, this is one of the systems which OpenBSD
won't support because it requires a "blob" -- a chunk of pre-compiled
code from the vendor which can't be source code examined for security
holes and patched. Instead, you have to run it in your OS from within a
wrapper to make it look right to the OS. This is one of the reasons
that OpenBSD does not like linux -- too many linux distributions have
accepted the blob and the restrictive terms which come with it.
> I have also used Promise
> IDE RAID cards. All that stuff is usually on the motherboard today. I
> also have a StorageWorks cabinet that used to be connected to a VAX
> Cluster using CI bus that I will be using via SCSI for otther systems
> now that the VAX are all gone. But that's a SAN and a bit more than your
> average RAID. :-)
O.K.
>>
>> The only one which we tried which seemed bulletproof was the one
>> by DEC.
>>
>> But I have three A-1000/D-1000 boxes -- one converted to JBOD,
>> the other two hardware RAID -- and the latter need special management
>> programs in Solaris which are not upgradable to Solaris 10 (and not
>> available at all for OpenBSD.
>>
>> But the zfs seems to be *very* reliable on either a Sun Blade
>> 2000 or a Sun Fire 280R.
>
> I've used Vinum to get software RAID and it was OK, but recovery seems
> to go much better with hardware RAID. At least in my experience.
While my experience is better with software raid in the form of
zfs. The earlier software RAID in Solaris (the one with all the "meta*"
commands) was a serious problem to work with in contrast.
looks as though Solaris 10 does have support for several
hardware RAID cards:
======================================================================
aac aac (7d) - SCSI HBA driver for Adaptec AdvancedRAID Controller
chs chs (7d) - IBM ServeRAID PCI host adapter driver
dpt dpt (7d) - DPT ServeRAID IV SCSI host bus adapter and RAID adapter driver
lsimega lsimega (7d) - SCSI HBA driver for LSI MegaRAID 320-2x SCSI RAID Controller
======================================================================
>>>
>>> Run BSD at work all the time. Never saw a reason for 15 partitions.
>>
>> Well ... perhaps with the new 1 TB and 2.5 TB drives. :-)
>
> Nope, still don't see a need for all them partitions. If I have a need
> for multiple partitions it is much better to use multiple drives.
Perhaps if you were running a web server for multiple users, and
you wanted to be sure that one user could not hog space from another,
put each on his own partition. :-)
>> I think that machines like the Sun Blade [12]000 and Sun Fire
>> 280R are not going to work as well on any available BSD as they do on
>> Solaris 10.
>
> But that is because Sun is able to put stuff into Solaris that BSD
> can't. If Sun had stuck to BSD then their version of BSD would
> perform just as well and probably better.
Perhaps. I've come to be comfortable with Solaris, especially
Solaris 10.
>>
>> [ ... ]
>>
>>>>>
>>>>> But suffered fromt he same problem that IBM found with their idea to use
>>>>> the M68K. :-)
>>>>
>>>> Political?
>>>
>>> Yes. Came from the same vendor as the M68K.
>>
>> So they did not like the Vendor? Nothing to do with the
>> hardware?
>
> It was not a matter of like or dislike as much as a matter of control or
> not control.
Oh -- they could control what Intel did, but not Motorola.
Thad Floryan
> On 2009-01-19, Thad Floryan <t...@thadlabs.com> wrote:
>
[...]> > Thus, there are still some 1.5 billion IPv4 addresses
> > available (less the 10.*.*.*, 172.[16-31].*.* and 192.168.*.*
> > and the link-local 169.254.*.* and loopback 127.*.*.*).
>
> And my internal ones are in the 10.*.*.* region.
Hah, I did the same thing, too, unless it caused problems
with VPNs to clients. hotels and convention centers who also
used 10.& for their LANs.
So, I switched my LAN IP to 223.15.22.*. The "223" is my
favorite rifle caliber and the "15.22" is my street address
(actually just 1522). That worked fine for years until I
noticed allocations beginning to encroach, so I changed my
home office LANs to the 20-bit blocks 172.19.19.* and
172.20.20.* where they'll remain until the day I no longer
use computers.
Using the 172.* means I no longer have VPN conflict problems
with any 10.* or 192.168.* LAN networks.
Bill Gunshannon
Of course not. It was another discussion but I still find it amazing that
SCSI disk prices have not come down like others. There is nothing new or
revolutionary in SCSI. What is keeping the prices up there?
>
> And there are still people who have dialup connections, and the
> download time for the updated maps would be a killer for them.
The maps are for the MTA's, not the users. The user sends his message
using the same address syntax he does now. The MTA handles the routing.
That's what they're for and why we have MTA's. :-)
>
>> The database would not change all that often except for minor additions
>> and deletions.
>
> How many end users change ISPs in the US per day? How about in
> the world. A bang path has to find its way to the user's machine, or
> the user's ISP's mail server. Since I run my own mail servers, I
> consider that it has to reach *my* machines.
And? If I change ISP's what effect does that have on the MTA's? Forget
this "bang path" stuff. It is irrelevant. It was only in the very early
days of even UUCPNET that users actually had to supply the whole path
from one user to another. Start thinking of it just like IP. Your PC
does not know the route to every other machine in the world. All it has
to know is your address, the destination address and a next hop. Email,
using the UUCP method, can work exactly the same way. Stop thinking in
terms of UUCP as it was 40 years ago. I only suggest using UUCP because
it still exists, it is available on probably 95% of the machines running
as MTA's today and, it requires the one thing that is the basis for why
this method would be so much better than what we have today. Peering!
The idea that there is an agreement between people exchanging email at
the MTA level so that there is a real way to guarantee that anti-social
behavior will not be tolerated.
>
>> One could even apply SPF algorithms so that the problem
>> of the disappearing link (something else that while rather common in the
>> old days would be very unlikely today) would not eb there either.
>
> How do you intend to make this work? What does your bang-path
> look like as you plan the new system?
Who cares what the bang paths look like? What does the traceroute from
you to me look like? You don't know and you (probably) don't care. It
is irrelevant.
> How is a user to select an end
> system if the system names are duplicated.
Why would system names be duplicated? They aren't now. Email to cs.uofs.edu
come here. Nowhere else.
> (And I say *system* names,
> not domain names.
What's the difference?
> The FQDN replaced bang paths, so if you are going
> back to bang paths, it would seem that you are getting rid of the FQDN.
You brought up bang paths. I have been saying all along that emai would
continue to use FQDN. Stop thinking of things as the were 40 years ago.
Times have changed. We have learned a lot. Look at the example of the
bang path I posted for my old address.
UUCP: {philabs}\
{phri } >!trotter.usma.edu!bill |
{sunybcs}/
Note the "machine name" immediately before my username. That was 30 years
ago and we already were using domain qualified names in UUCP.
>
>>>
>>>>> -- and a lot of them would fight it tooth and nail.
>>>>
>>>> If done correctly, they would never even now a change occured!
>>>
>>> Except for the greater number of messages falling through the
>>> cracks as systems are shut down.
>>
>> Do you mean end-points shutting down? How would that be any differnt than
>> today? If you mean intermediate links shutting down, just like with News
>> (which, while using NNTP, still just emulates the same store and forward
>> model used by the original system)
>
> Uucp mail (via bang paths) was to store and forward to a single
> system closer to the destination.
Again, your thinking 40 years ago when we could only connect to the closest
site. But even then, that was due to cost and not some technical limitation.
Remember my mentioning UUNET? When they started, how many sites all over
the country (the world?) arranged to connect to them directly thus making
their path one hop to every other machine cinnected to UUNET. Today, we
are one hop, physically, away from everybody. The only thing that will
add hops is going to be the peering agreements as it is unlikely that
anyone will have a peering agreement with everyone. But, there is no reason
why we can't see a dozen or even several dozen sites that will set themselves
up as "hubs", much like UUNET was and take on peering with hundreds of other
MTA's. Of course, it really doesn't matter all that much because, where
a link of 10 hops could easily take 2-3 days to traverse in the old days,
it would take seconds (or worse case, minutes) today because the medium
between sites is faster and available at all times.
>
> News (also via bang paths) was to store and broadcast to all
> other known news server connections.
But the true value is not in the path but in the idea that the people
exchanging news are peers, not random machines on the INTERNET. Without
an agreement with someone that they will send you news and accept it from
you, you can not play. the same social contract is the only way to clean
up email.
>
> If one system goes down, *news* gets there via other paths, but
> email bang paths die at the dead system,
Why does that have to happen? Why can one not have multiple paths?
And more important than that, we are talking MTA's here, not Joe User's
PC. How often does Verizon's email MTA go down? If it does, how long
is it likely to stay down? I can tell you that the MTA I run here has
never been down on it's own accord. The only times it has been unavailable
was when the whole University went off the net. Most sites see the MTA as
a 24x7 operation.
> because they are not broadcast
> to all known connections. You don't *want* something addressed to an
> individual to be broadcast all over the world. :-)
Once again, look at the IP model. Packets are not "broadcast" to every
router in the world. The are sent to the next hop. And, in most cases,
if a hop disappears they are routed around it. Why is it so hard to imagine
email doing the same thing?
>
>> it is unlikely any major player would
>> have a single connection making routing around failures easy.
>
> You're assuming that there will only be major players in the
> game.
There will only be major players in the game. The whole idea of this is
to get Joe User and hos zombied PC out of the picture.
> Bang paths often went through a number of other small systems
> before they got to a backbone system. At first, my outgoing email was:
>
> dnichols@ceilidh!beartrack!uunet!username@FQDN
And, why was that? Probably because you ahd to connect to the nearest
(cost-wise, not distance-wise) system to you. Why did you not contact
UUNET directly? I know why I wouldn't have. :-) But today, everybody
can connect directly to everybody else. That's how SMTP works. All I
am trying to do is put a social layer between the technical method and
the user because SPAM is a social problem and can not be solved with a
contrived technical solution. We don't have to use UUCP to do this.
A whole new Email system could be devised that would provide this. How
long you think that would take? What do you think the acceptance rate
would be? I am only suggesting using UUCP because it already exists,
we know it works and it solves the problem.
>
> and that was only because uunet was really using the FQDN and smtp to
> move e-mail around. "beartrack" was owned by a friend, and he forwarded
> my outgoing and incoming e-mail to/from uunet,
And, why didn't you connect directly to UUNET yourself? Bet it was the
cost.
> who then converted it to
> FQDN format.
Many of the sites that uunet used FQDN for were actually being delivered
to via UUCP. Look at my UUCP address. Just because the order is back-
wards and there is a "!" instead of the "@" we are so used to today, it
is still an FQDN. And it was used in UUCP over 25 years ago. The form
of an address is just a red herring. One could also send email to
addresses like SCRANTON.BITNET from a uucp connected host.
>
>> As a matter
>> of fact, the reason for only having a few connections under the old UUCP
>> system no longer exists so having dozens (or even hundreds) of peers is
>> not really a problem.
>
> You are assuming that the current FQDN system is kept alive so
> connections to other systems is cheap.
Huh? What dopes the format of an email address have to do with connectivity?
Or are you anticipating the demise of the INTERNET? As long as all the
machines exchanging email are on the INTERNET, connections are cheap if
not free (or rather free of additional cost for handling email).
> But how is this bang-path then?
Forget this bang-path crap. That is nothing more than an obsolete form of
notation. It is not necessary for using UUCP to send email between MTA's.
All that is necessary is agreement between the MTA's that they will accept
each others email and routing.
>
> And do *you* really want to broadcast your e-mail to every
> machine in the world
Yet another red herring. Where did I ever say I wanted to do this. Email
has never done this. UUCP didn't do this. even NNTP doesn't really do that.
It still only goes to people who have agreed up front to be peers.
> -- making it easy for projects like "carnivore" to
> study everything, and making the load on small severs rather
> overwhelming. Usenet is intended for the world, so broadcast
> distribution makes sense. Email is not.
No one ever said it was. Let's go back a few years (OK, a few decades :-).
No NNTP. No SMTP. Machines are exchanging News and Email. One is being
"broadcast" (your term, not mine) and the other is simple point-to-point
from one user to another. What is the underlying protocol? Hmmmm....
UUCP. Damn, it does both. I am merely suggesting using a differnt
TRANSPORT Protocol to handle email than the one being used today. Why?
Because the one in use today is flawed, not technically, but socially.
And I don't see anyone working on a solution. So, until someone does
start workingon a solution I am merely suggesting we take something we
already have and adapt it to do the job and fix the problem.
>
>> And once you eliminate the SPAM and other anti-social
>> practices the system becomes almost maintenance free. Certainly a lot less
>> maintenance than it takes to run a decent MTA today.
>
> IIRC, bang paths took a lot of maintenance.
Well, I ran UUCP machines. Trust me, trying to keep up with all the
new and constantly eveolving SPAM methods takes a lot more maintenance.
And, is doomed to failure. Worse still, it fails in two differnt ways.
One is that you still get SPAM and the other is that you don't get
legitimate emails and may never know that you didn't get it.
> Again -- are you
> planning to continue to use the DNS which supplanted bang paths, and
Forget this bang-path stuff. It's notation, nothing more. UUCP is not
bang-paths it is a protocol for transfering files betweem machines that
requires that active peering agreed to by both parties is in place. It
can be used to send Email, News or even files!!
> just turn off port 25 (smtp) and replace it with something else?
Wether or not an MTA turns off port 25 and drops SMTP entirely is his
business. One of the nice things about this system is the fact that
it can be started in paralel with the existing system and phased in
gradually. One system is known clean and the other is always suspect.
Makes marking emails as CLEAN or POSSIBLE-SPAM very easy. But that is
only a side item and not the primary purpose of my proposal.
> If so,
> how do you keep the spamers from figuring out how to manipulate *that*
> system as well?
Let's see, I have an MTA. I agree to exchange email with you. We have
a signed agreement that says I will not let my users send SPAM. What
do you think happens if I decide to let one of my users send SPAM? You
pull the plug and possibly seek civil redress for breach of contract
with me. No one can play (at the level of the MTA) without an existing
peering agreement with some other MTA who is a part of the network. No
zombied PC's. No just setting up a machine on the INTERNET and blasting
out SPAM to any MTA you can connect to on port 25. If yo are not in my
L.sys file I don't talk to you. Period.
>
>>>
>>>>> Aside from that -- bang paths are vulnerable to a single machine
>>>>> in the path going out of service between the receipt of the incoming
>>>>> e-mail and the sending of the reply.
>>>>
>>>> Considering the nature of connectivity over the INTERNET, there should
>>>> be no one of consequence with any single path to any other location.
>>>
>>> What would a bang path look like which used the internet for
>>> connectivity? You still need to know names of systems at each end at
>>> the least.
>>
>> Who needs to know? The user? Not hardly. The MTA's need to know and they
>> do. That's what comp.mail.maps was for. The MTA's use this data to build
>> a database of destinations. Just like IP, they really only need to know
>> the next hop to their destination. The users would continue to use the
>> same addressing they use today.
>
> But an outgoing bang path needed the full list of machines on
> the way.
No, just because it used to work that way doesn't mean it has to be that
way. One machine need only know the next hop.
> *This* is what would make tracking spam back easier.
In my system, SPAM becomes a one time occurance, if at all. Think of the
result of sending SPAM as the Amish custom called shunning. :-)
> If you
> don't have that, you just have a somewhat slower name lookup process
> with a greater chance of errors.
Why? First, logs would make tracking easy. Second, because only peers
are able to exchange email anyway, there would be no header forging.
Third, what would make the lookup slower? I can think of at least two
different ways to handle lookups (one just came to me now) and both
would be no slower than a current DNS lookup. And the chance of error
is no greater than today, or have you not heard of thngs like DNS poisoning?
>
>> One of the nice things about this is one could actually handle email
>> with both systems and phase the new system in over time. The old
>> SPAM ridden system could remain for those who prefer to not play
>> but for those of us who would really like to see email become usable
>> for real communications again we have the new, clean system.
>>
>>> And IIRC, uucp required that there be no two systems with
>>> the same name -- making a naming problem with the number of machines in
>>> use today.
>>
>> Same thing exists now. There can not be another cs.uofs.edu anywhere
>> on the INTERNET. So, what's the problem? Or are you assuming we would
>> still be stuck with single word names of no more than 8 characters?
>
> You have a FQDN there, not just a system name. Your system name
> is 'cs', and how many 'cs' machines are there at colleges around the
> country?
Actually, no it's not. Machine name is mailhost. You are once again
confusing an email address with a machine name. They are not the same.
> *That* is the duplication which had to be avoided for
> comp.mail.maps to work.
And, again, if you look at my old UUCP address/path you will see that
FQDN was supported for UUCP 25 years ago. No duplicaion of names.
>
> And think of the number of PCs running Windows which get a
> default name which matches every other system from the same CD-ROM
> distribution.
So what. Shutting them out of the system is one of the primary reasons
for this idea. The largest percentage of SPAM comes from those PC's that
are not MTA's and should not be allowed to send email anyway.
>
>>> After all -- without domain names, it is difficult for a
>>> database to distinguish between systems with the same name to generate
>>> the proper bang path.
>>
>> Why would we not have domain names?
>
> Because they are not used in normal bang paths.
There you go with that bang-path crap again. This is not 1980. We don't
have to use that notation. It is not an inherent part of UUCP it is merely
the notation used by humans to envision what the network looked like. It
has nothing to do with the actual transfer of data from one machine to another.
>
> Again I ask -- just what would your addressing look like with
> the revived bang path which you are advocating? Until I see that, I
> can't see how it would work in today's environment.
Well, my address would look like "bill...@cs.uofs.edu". Look familiar?
All the nuts and bolts stuff of how one machine gets to another is
handled by that man over there behind the curtain. It would work just
like IP does. You don't know what path is used to get from your PC
to www.google.com. And you probably don't care. What's more, it may
not be the same tomorrow as it is today. And you don't care about that
either. there is no reason why email, using the UUCP protocol as its
transport can't be done the same.
>
>>> The example which I showed above only used uucp to get to uunet.
>>> From there, things went by domain name.
>>
>> Yes, and many of those machines connected by domain name were UUCP
>> machines. Look at the example I posted earlier of what my address
>> was.
>> trotter.usma.edu!bill
>>
>> There's a three part domain style name used in a bag path. yes, it worked
>> just fine.
>
> But it required a system which understood FQDNs.
Name one today that doesn't?
>
>> And from the ARPANET dise of the house it was:
>> bi...@trotter.usma.edu
>>
>> Both worked just fine. That was 25 years ago. We have gotten a bit better
>> at doing this stuff since then. :-)
>
> You are talking about the merge between bang paths and FQDNs,
> not pure bang paths.
Forget bang-paths. They have nothing to do with using UUCP as a transport
protocol. They are a notation intended to allow humans, not computers,
to visualize the network.
> And I fail to see what benefit that would offer,
> as it would not keep a track of the machines a spam passed through on
> the way to you.
There is no SPAM. People running MTA's will have a real (as in with real
teeth) reason to not allow their users to SPAM as it would result in their
loosing the ability to do email at all and might result in civil, financial
penalties. And, as stated above, logs (which have been found to be legally
binding in a court of law) will still record every machine an email passed
thru. And, because email only passes between peers anyway, determining
the paths is easy. Additionally, because the logs are maintained not
as a part of the email but sparately ther eis no chance of forging.
One could even go so far as to stop including path information in the
headers of the eamil altogether. We have them now, but they are of
dubious if any value because of the ease of forging them.
>
>>>> The one thing to remember, is that unlike the days of doing this over
>>>> the phone lines there is no additional cost for connecting to any
>>>> other location. And you don't have to wait til after midnight when the
>>>> rates go down. :-)
>>>
>>> So -- how is it done without domain names between the main trunk
>>> servers at least? *Pure* bang paths required the name of every system
>>> between the origin and the destination.
>>
>> See comments above. The biggest problem I am having selling this idea
>> seems to be that rather than looking at what it would take to make it
>> work everyone I talk too just assumes because we did it 25 years ago
>> and don't do it now it must not be possible. Stop looking for problems
>> and start looking at solutions.
>
> While I'm having difficulty seeing how it would be implemented
> with today's systems
It is implemented. I am aware of no version of Unix that does not still
have UUCP. It is a simple matter of adding (or rather, probably just
uncommenting) an entry in sendmail or postfix (or whatever MTA you use)
to have some or all of your email routed through UUCP as its transport
protocol. The rest is merely finding peers and signing agreements with
them.
> -- and what it really would do better?
It totally eliminates random or anonymous email MTA's. And that is
where the vast majority of SPAM comes from.
>
> And uucp needs the delivering systems to be given a login
> (restricted to uucp only, but still a path into your or my system).
Part of the concept of peering. That is what eliminates the ability for
Joe Random User to inject SPAM or anything else into the system.
>
>>>
>>>>> But it would sure make it easy to track down the originator of
>>>>> spam -- or at least the compromised machine sending it out. :-)
>>>>
>>>> It certainly would. Which is why I mentioned the ability to assign
>>>> civil liability. Because no one could send email without going through
>>>> a legitimate MTA (no more need for RBL's to try and figure out if that
>>>> machine is a dial-up residential connection) the responsibility for
>>>> controlling users falls on the service provider. If he wishes to
>>>> remain in the email network, he controls his users. If he chooses
>>>> not to, he will find himself with no one willing to peer with him.
>>>> He is out of business.
>>>
>>> If the ISPs would simply block port 25 for all DHCP and dial-up
>>> systems, you would have the same conditions.
>>
>> Yes, but they don't and won't.
>
> You and Thad seem to disagree here.
Do you run an email MTA? Do you ever look at the logs? Every attempted
connection from a dial-up, DSL or Cable system is an ISP that does not
block port 25. If they actually did, we would not need RBLs'.
>
> I agree that too many don't.
The majority don't.
>
>> Because my system requires the exchanging
>> MTA's to be peers, all the rules are set up ahead of time. You agree to
>> do certain things in order to be a part of the network. Don;t agree, you
>> don't get to play. Agree and then violate the agreement, civil liability
>> for breach of contract. There are really no agreements for ISP's to join
>> the INTERNET. That's why nothing can be done. They can always fall back
>> on the argument that there is nothing wrong with what they or their users
>> are doing. A social problem, requiring a social solution.
>
> Given that some of the largest ISPs are offenders (like Verizon,
> Comcats, road-runner, and others), how long do you think it would take
> for them to claim "But you *can't* shut us down and deprive all of these
> hundreds of thousands of people of their e-mail." Just the problem we
> have with the current system.
So, where does it say that I have to accept email from anyone? The sole
putpose of the RBL projects is to block email from these suspect locations,
like Verizon and Comcast. But that is a reactive solution and requires
that you have information that these sites are not going to provide. My
system is proactive and reverses the process. Rather than trying to
block machines I have no way of identifying I merely set up a system that
that says I will only accept email from those who agree to play nice in
the sandbox. And, like I have tried to explain, this doesn't preclude
my also accepting email from sources outside of my closed system. But
I will have the ability to clearly mark what came from a guaranteed
clean feed and what comes from a suspect feed. My users can then filter
to their hearts content. If a user chooses to not accept any email that
comes from other than a clean feed he can. Personally, I feel that if this
system got a chance it would take very little time before the majority
of legitimate sites became members and the people who need and use email
for serious purposes, like business and research, would find it a much
more manageable system, like it used to be before some idiot decided to
open it up to the masses.
>
> [ ... ]
>
>>> O.K. Did you ever run ultrix on a system? My friend has the
>>> tapes for that acquired from one of the systems he got.
>>
>> Not only have, but still do. My systems were used by Frank da Cruz to
>> build the last couple of binary C-Kermit programs at Columbia.
>
> O.K.
>
> [ ... ]
>
>>>>> Hmm ... I remember being shocked when I heard that DEC claimed
>>>>> POSIX compliance for VMS. :-)
>>>>
>>>> They wrote a POSIX system that ran on top of VMS (exactly the way EUNICE
>>>> worked) that met the requirements. As far as I know, they later abandoned
>>>> the project.
>>>
>>> O.K. Before DEC abandoned doing business entirely.
>>
>> Well, I meant DEC and theiur successors. The POSIX Kit was around for
>> a while, but I believe thay have dropped it at this point.
>
> Is there someone keeping VMS going? Someone making the hardware
> for it?
Cetainly. It went from VAX to Alpha and now runs on Itanium. It belongs
to HP.
>>>
>>> [ ... ]
>>>
>> Then you need a commercial connection and not a residential connection.
>> I am sure they offer commercial service (FIOS is a purely residential
>> concept although businesses could probably use the voice and network
>> part) but you probably don't want to pay the price.
>
> I'm already paying the price for a T1 connection. The question
> is how much more or less would they ask for the same?
You have a residential T1? :-)
>
> But I keep getting calls from salesmen wanting to sell me a
> *residential* FIOS feed.
That's just business. I still get ads wanting me to buy direct TV and I
already have it. And, of course, even though I dumped them close to 10
years ago because of poor service the cable company is still trying to
get me to sign up.
>
>> Most ISP's I am
>> aware of specifically prohibit running servers on residential connections.
>
> I have a business account. I have static IPs, and run both mail
> and web servers on them.
I guess I lost track of what the problem was then. You can pretty much
do anything that's not illegal on a business connection.
>
>> I know one guy locally who is constantly trying to get around this. I
>> am surprised the ISP hasn't just terminated his service instead of playing
>> hide-and-seek with his web server.
>
> Why not simply buy a business account as I did.
Cause he's not a business and he doesn't want to pay the money. He's
just a gamer and a wannabe hacker.
>
>>> I probably could talk to their business account division and get
>>> something more to my liking -- without the cable-TV and phone rolled in.
>>> I particularly don't like the FIOS for phone because there is a limited
>>> time that you can lose power before the local electronics run out of
>>> battery charge.
>>
>> I have always been leary of these INTERNET Phone services. If your
>> service goes out, how do you report it? You have to have some alternate
>> phone service. Considering how seldom I even use my phone at home my
>> next location may not have landline phone service at all. I carry one
>> on my belt, why would I need another?
>
> This is not exactly an internet phone service. It is a fiber
> optics feed which provides phone, cable, and internet through the same
> fiber.
Well, the way I understand it all you really get over the fiber is
INTERNET. Everything else is delivered as IP services. VOIP and
digital TV. The liklihood of the VOIP or TV going out n their own
is slim, but if you loose INTERNET, you loose everything.
>
> [ ... ]
>
>>>>>> Yeah, that was a great example of the shortsightedness of people around
>>>>>> here.
>>>>>
>>>>> Where is "here"?
>>>>
>>>> Northeastern PA. Third or fourth largest metro area in PA.
>>>
>>> O.K. You are not that far away, then. I'm just to the West of
>>> DC in Virginia -- just outside the Beltway. And luckily, I don't have a
>>> need to go into DC for the next few days. :-)
>>
>> I used to work out of Rockville. I know VA pretty well, too. Used to
>> go to the Pentagon, Arlington and Reston a lot. Many years ago, however.
>
> Today would have been a bad time for that. Any traffic between
> VA and DC was shut down for most of the day. :-)
Actually, I used to live in Gettysburg, PA and commute. If I had to be
in VA early I used to go down 15 and come in from the west avoiding all
the rush hour traffic. I actually found (and still find) it easier to
get around down there than up here.
>
> [ ... ]
>
>
>>
>> Not sure what these are but they are not what I have. The VAX used a
>> ribbon cable as well as the QBUS to connect memory.
>
> Was the ribbon cable on the edge opposite the bus connectors?
Yes.
I would love that. I always liked San Antonio. But my wifes only taste of
Texas was Ft. Hood and now she won't go near the place. :-(
>
> [ ... ]
>
>>
>> Isn't the cardcage in a box with a power supply and front panel?
>
> Nope. Just the bare cardcage with four slots (IIRC) and a
> backplane. Some of the cards are single-wide and some double wide, with
> the CPU being double wide. Maybe it is only three slots. One 64K
> memory card, one quad serial port card, and one floppy controller card.
>
>> What you need is a real PDP-11 box!!
>
> Too big, too heavy. :-) And IIRC, DEC favored linear regulated
> power supplies instead of switching supplies, which makes it even
> heavier. :-)
Ummmm... No. Ihave many desktop or pedestal PDP-11's. UNIBUS boxes were
big, but not QBUS. And I wish they used real power supplies. A lot easier
to repair.
>
>> As for RSTS, no hobbyist
>> program for any of the non-Unix OSes. But, maybe someday.
>
> O.K. What OS is there likely to be for the LSI-11 then?
BSD, early versions of UCSD-Pascal. And then ther eis the one I plan on
writing when I get the time. :-)
>
> [ ... ]
>
>>>>
>>>> I have a SCSI one that I use quite a bit. The other would be usefull
>>>> as Pertec shows up as a different device than the SCSI one.
>>>
>>> Pertec was also a front-loading self threading system, IIRC. I
>>> had one of those connected to my first unix box -- the COSMOS
>>> CMS-16/UNX.
>>
>> Pertec is the interface.
>
> Pertec was probably also once a maker, just as the "centronics"
Yes, they were.
I have used numerous hardware SCSI solutions with FreeBSD. I have a
couple running right now. Bith SCSI and SATA.
Quotas takes care of that problem.
More spindles also greatly increases throughput. Learned that running
Usenet News Servers. :-)
>
>>> I think that machines like the Sun Blade [12]000 and Sun Fire
>>> 280R are not going to work as well on any available BSD as they do on
>>> Solaris 10.
>>
>> But that is because Sun is able to put stuff into Solaris that BSD
>> can't. If Sun had stuck to BSD then their version of BSD would
>> perform just as well and probably better.
>
> Perhaps. I've come to be comfortable with Solaris, especially
> Solaris 10.
>
>>>
>>> [ ... ]
>>>
>>>>>>
>>>>>> But suffered fromt he same problem that IBM found with their idea to use
>>>>>> the M68K. :-)
>>>>>
>>>>> Political?
>>>>
>>>> Yes. Came from the same vendor as the M68K.
>>>
>>> So they did not like the Vendor? Nothing to do with the
>>> hardware?
>>
>> It was not a matter of like or dislike as much as a matter of control or
>> not control.
>
> Oh -- they could control what Intel did, but not Motorola.
>
Well, once they bought 65% of Intel's stock they could. :-)
DoN. Nichols
> In article <slrngnddtn....@katana.d-and-d.com>,
> "DoN. Nichols" <dnic...@d-and-d.com> writes:
>> On 2009-01-19, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>>> In article <slrngn7rab....@katana.d-and-d.com>,
>>> "DoN. Nichols" <dnic...@d-and-d.com> writes:
[ ... ]
>>>>>>>>>> ceilidh!uunet!username@FQDN
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I keep trying to convince people that we really need to revive this email
>>>>>>>>> system. It offers the best and quickest solution to the SPAM problem but
>>>>>>>>> apparently I am the only one who can see that.
Here is where I picked up that you wanted to revive bang paths,
and it was not until recently that I have decided that you did not. Had
this been clear earlier, we could have saved a lot of words.
[ ... ]
>>>> How many MTAs automatically generate bang paths these days? And
>>>> you would still need a massive database to generate the bang path.
>>>
>>> Yes, but pretty much all of them can (except maybe Exchange! :-) In today's
>>> environment, the database would size would be trivial. 1TB disk : $129.00
>>
>> I not $127.00 for a SCSI or Fibre Channel version. :-(
>
> Of course not. It was another discussion but I still find it amazing that
> SCSI disk prices have not come down like others. There is nothing new or
> revolutionary in SCSI. What is keeping the prices up there?
The SCSI and FC drives are a higher reliability construction
than the IDE (and perhaps the SATA ones). The reliability does cost
more -- either production costs or more extensive testing.
I got a batch of FC drives in Eurologic bays, and most of them
showed up with over 50k hours on the clock -- 5.7 years. IDE drives
tend to die a lot sooner.
>>
>> And there are still people who have dialup connections, and the
>> download time for the updated maps would be a killer for them.
>
> The maps are for the MTA's, not the users. The user sends his message
> using the same address syntax he does now. The MTA handles the routing.
> That's what they're for and why we have MTA's. :-)
O.K. Except that *I* am running MTAs, and I don't want to
dedicate 1 TB of disk space to the task -- even if it were shared
between the two MTAs.
>>> The database would not change all that often except for minor additions
>>> and deletions.
>>
>> How many end users change ISPs in the US per day? How about in
>> the world. A bang path has to find its way to the user's machine, or
>> the user's ISP's mail server. Since I run my own mail servers, I
>> consider that it has to reach *my* machines.
>
> And? If I change ISP's what effect does that have on the MTA's? Forget
> this "bang path" stuff. It is irrelevant.
O.K. Now that it is clear that we are somehow using uucp
without bang paths -- O.K.
> It was only in the very early
> days of even UUCPNET that users actually had to supply the whole path
> from one user to another. Start thinking of it just like IP. Your PC
> does not know the route to every other machine in the world. All it has
> to know is your address, the destination address and a next hop. Email,
> using the UUCP method, can work exactly the same way. Stop thinking in
> terms of UUCP as it was 40 years ago. I only suggest using UUCP because
> it still exists, it is available on probably 95% of the machines running
> as MTA's today and, it requires the one thing that is the basis for why
> this method would be so much better than what we have today. Peering!
The only problem that I see with this is that uucp is commented
out in most systems these days (for security reasons). As a result, it
has not received the level of scrutiny that even sendmail has -- and
you know how long they have been reporting the "last security hole
*ever* has just been plugged in sendmail". :-)
I personally don't *trust* uucp as it sits.
> The idea that there is an agreement between people exchanging email at
> the MTA level so that there is a real way to guarantee that anti-social
> behavior will not be tolerated.
O.K. That I can see.
>>
>>> One could even apply SPF algorithms so that the problem
>>> of the disappearing link (something else that while rather common in the
>>> old days would be very unlikely today) would not eb there either.
>>
>> How do you intend to make this work? What does your bang-path
>> look like as you plan the new system?
>
> Who cares what the bang paths look like? What does the traceroute from
> you to me look like? You don't know and you (probably) don't care. It
> is irrelevant.
Actually -- I often use traceroute to see what the path between
my systems and some others happens to be at the moment -- trying to
figure out what is causing the system to be unreachable or very slow.
So I *do* care from time to time. :-)
Since it is clear that we are keeping FQDNs, I'll snip a lot of
this out.
[ ... ]
> UUCP: {philabs}\
> {phri } >!trotter.usma.edu!bill |
> {sunybcs}/
>
> Note the "machine name" immediately before my username. That was 30 years
> ago and we already were using domain qualified names in UUCP.
My 3B1s did not understand FQDNs, and just treated them as
another string which was a system name. It was up to uunet to deal with
the domain name itself.
(Actually, most of them *did* understand FQDNs, because I had
several ethernet cards for them, and the WillGoWrong TCP/IP package. :-)
[ ... ]
>> If one system goes down, *news* gets there via other paths, but
>> email bang paths die at the dead system,
>
> Why does that have to happen?
Because I was assuming traditional bang paths. Now I am not.
[ ... ]
>> because they are not broadcast
>> to all known connections. You don't *want* something addressed to an
>> individual to be broadcast all over the world. :-)
>
> Once again, look at the IP model. Packets are not "broadcast" to every
> router in the world. The are sent to the next hop. And, in most cases,
> if a hop disappears they are routed around it.
Yes -- it is slower to come back on line, but it does eventually
get there.
> Why is it so hard to imagine
> email doing the same thing?
Because I was fixated on the bang path, which had all the
machine names hard-coded in it, and no provision for updating on the
fly.
>>
>>> it is unlikely any major player would
>>> have a single connection making routing around failures easy.
>>
>> You're assuming that there will only be major players in the
>> game.
>
> There will only be major players in the game. The whole idea of this is
> to get Joe User and hos zombied PC out of the picture.
I want *him* out of it -- but I don't want to be shut out of
running my own MTAs.
>> Bang paths often went through a number of other small systems
>> before they got to a backbone system. At first, my outgoing email was:
>>
>> dnichols@ceilidh!beartrack!uunet!username@FQDN
>
> And, why was that? Probably because you ahd to connect to the nearest
> (cost-wise, not distance-wise) system to you. Why did you not contact
> UUNET directly?
Because I wanted to get the bugs out of the setup (configuration
of UUCP, etc) *before* I started paying money to uunet. And I had a
friend at the other end. Physically, it was from me in VA to Maryland,
and then back to uunet in Virginia not too far away. :-)
> I know why I wouldn't have. :-) But today, everybody
> can connect directly to everybody else. That's how SMTP works. All I
> am trying to do is put a social layer between the technical method and
> the user because SPAM is a social problem and can not be solved with a
> contrived technical solution. We don't have to use UUCP to do this.
> A whole new Email system could be devised that would provide this. How
> long you think that would take? What do you think the acceptance rate
> would be? I am only suggesting using UUCP because it already exists,
> we know it works and it solves the problem.
But we don't know about its security in the face of modern
attacks. I have *never* allowed a uucp connection to/from my systems
via the internet.
And this puts more passwords out there for people to try to
crack, either by brute force, or by capturing /etc/shadow and running
crack or jack-the-ripper against it.
Granted, I believe that I have good secure passwords, but with a
uucp port open, I would never be sure who might have gotten a copy to
attack.
>> and that was only because uunet was really using the FQDN and smtp to
>> move e-mail around. "beartrack" was owned by a friend, and he forwarded
>> my outgoing and incoming e-mail to/from uunet,
>
> And, why didn't you connect directly to UUNET yourself? Bet it was the
> cost.
Nope! That was why I *dropped* UUNET -- when they kicked the
TeleBit WorldBlazers off line and replaced them with something nominally
faster, but much slower for uucp traffic.
The first move was to a SLIP connection to digex (after finding
someone who ran it at a hamfest).
>> who then converted it to
>> FQDN format.
>
> Many of the sites that uunet used FQDN for were actually being delivered
> to via UUCP. Look at my UUCP address. Just because the order is back-
> wards and there is a "!" instead of the "@" we are so used to today, it
> is still an FQDN. And it was used in UUCP over 25 years ago. The form
> of an address is just a red herring. One could also send email to
> addresses like SCRANTON.BITNET from a uucp connected host.
Yes -- but it *originally* sounded like you wanted to go back to
traditional bang paths.
[ ... ]
>> And do *you* really want to broadcast your e-mail to every
>> machine in the world
>
> Yet another red herring. Where did I ever say I wanted to do this. Email
> has never done this. UUCP didn't do this. even NNTP doesn't really do that.
> It still only goes to people who have agreed up front to be peers.
You were talking about working around dead systems the way
usenet does -- and that depends on broadcast delivery, not
point-to-point.
[ ... ]
>>> And once you eliminate the SPAM and other anti-social
>>> practices the system becomes almost maintenance free. Certainly a lot less
>>> maintenance than it takes to run a decent MTA today.
>>
>> IIRC, bang paths took a lot of maintenance.
>
> Well, I ran UUCP machines. Trust me, trying to keep up with all the
> new and constantly eveolving SPAM methods takes a lot more maintenance.
That is maintenance in a different field -- filtering instead of
connectivity. :-)
> And, is doomed to failure. Worse still, it fails in two differnt ways.
> One is that you still get SPAM and the other is that you don't get
> legitimate emails and may never know that you didn't get it.
Certainly.
[ ... ]
>> If so,
>> how do you keep the spamers from figuring out how to manipulate *that*
>> system as well?
>
> Let's see, I have an MTA. I agree to exchange email with you. We have
> a signed agreement that says I will not let my users send SPAM. What
> do you think happens if I decide to let one of my users send SPAM? You
> pull the plug and possibly seek civil redress for breach of contract
> with me. No one can play (at the level of the MTA) without an existing
> peering agreement with some other MTA who is a part of the network. No
> zombied PC's. No just setting up a machine on the INTERNET and blasting
> out SPAM to any MTA you can connect to on port 25. If yo are not in my
> L.sys file I don't talk to you. Period.
And -- if the spamers find out how to impersonate systems which
*are* in your L.sys file, they can talk to you and spew spam out from
*your* system, thus getting you disconnected from the world.
[ ... ]
> No, just because it used to work that way doesn't mean it has to be that
> way. One machine need only know the next hop.
>
>> *This* is what would make tracking spam back easier.
>
> In my system, SPAM becomes a one time occurance, if at all. Think of the
> result of sending SPAM as the Amish custom called shunning. :-)
O.K.
[ ... ]
>>>> And IIRC, uucp required that there be no two systems with
>>>> the same name -- making a naming problem with the number of machines in
>>>> use today.
>>>
>>> Same thing exists now. There can not be another cs.uofs.edu anywhere
>>> on the INTERNET. So, what's the problem? Or are you assuming we would
>>> still be stuck with single word names of no more than 8 characters?
>>
>> You have a FQDN there, not just a system name. Your system name
>> is 'cs', and how many 'cs' machines are there at colleges around the
>> country?
>
> Actually, no it's not. Machine name is mailhost. You are once again
> confusing an email address with a machine name. They are not the same.
O.K. But the *original* bang paths used machine names
exclusively.
[ ... ]
>>>> The example which I showed above only used uucp to get to uunet.
>>>> From there, things went by domain name.
>>>
>>> Yes, and many of those machines connected by domain name were UUCP
>>> machines. Look at the example I posted earlier of what my address
>>> was.
>>> trotter.usma.edu!bill
>>>
>>> There's a three part domain style name used in a bag path. yes, it worked
>>> just fine.
>>
>> But it required a system which understood FQDNs.
>
> Name one today that doesn't?
My 3B1s if I don't install TCP/IP and ethernet cards. :-)
>> as it would not keep a track of the machines a spam passed through on
>> the way to you.
>
> There is no SPAM. People running MTA's will have a real (as in with real
> teeth) reason to not allow their users to SPAM as it would result in their
> loosing the ability to do email at all and might result in civil, financial
> penalties. And, as stated above, logs (which have been found to be legally
> binding in a court of law) will still record every machine an email passed
> thru. And, because email only passes between peers anyway, determining
> the paths is easy. Additionally, because the logs are maintained not
> as a part of the email but sparately ther eis no chance of forging.
> One could even go so far as to stop including path information in the
> headers of the eamil altogether. We have them now, but they are of
> dubious if any value because of the ease of forging them.
O.K.
[ ... ]
>> While I'm having difficulty seeing how it would be implemented
>> with today's systems
>
> It is implemented. I am aware of no version of Unix that does not still
> have UUCP. It is a simple matter of adding (or rather, probably just
> uncommenting) an entry in sendmail or postfix (or whatever MTA you use)
> to have some or all of your email routed through UUCP as its transport
> protocol. The rest is merely finding peers and signing agreements with
> them.
And -- trusting that uucp security is sufficient to the task. I
don't believe that it is at present.
>> -- and what it really would do better?
>
> It totally eliminates random or anonymous email MTA's. And that is
> where the vast majority of SPAM comes from.
O.K.
[ ... ]
>>>> If the ISPs would simply block port 25 for all DHCP and dial-up
>>>> systems, you would have the same conditions.
>>>
>>> Yes, but they don't and won't.
>>
>> You and Thad seem to disagree here.
>
> Do you run an email MTA?
Yes.
> Do you ever look at the logs?
Frequently -- with scripts analyzing the logs as well.
> Every attempted
> connection from a dial-up, DSL or Cable system is an ISP that does not
> block port 25. If they actually did, we would not need RBLs'.
I never said that they did block prot 25. It was *Thad* who
said that. I know better.
[ ... ]
>>>> O.K. Before DEC abandoned doing business entirely.
>>>
>>> Well, I meant DEC and theiur successors. The POSIX Kit was around for
>>> a while, but I believe thay have dropped it at this point.
>>
>> Is there someone keeping VMS going? Someone making the hardware
>> for it?
>
> Cetainly. It went from VAX to Alpha and now runs on Itanium. It belongs
> to HP.
O.K. Is that still compatible at binary level with the earlier
systems?
>>>>
>>>> [ ... ]
>>>>
>>> Then you need a commercial connection and not a residential connection.
>>> I am sure they offer commercial service (FIOS is a purely residential
>>> concept although businesses could probably use the voice and network
>>> part) but you probably don't want to pay the price.
>>
>> I'm already paying the price for a T1 connection. The question
>> is how much more or less would they ask for the same?
>
> You have a residential T1? :-)
Yes. And it costs.
>> But I keep getting calls from salesmen wanting to sell me a
>> *residential* FIOS feed.
>
> That's just business. I still get ads wanting me to buy direct TV and I
> already have it. And, of course, even though I dumped them close to 10
> years ago because of poor service the cable company is still trying to
> get me to sign up.
>
>>
>>> Most ISP's I am
>>> aware of specifically prohibit running servers on residential connections.
>>
>> I have a business account. I have static IPs, and run both mail
>> and web servers on them.
>
> I guess I lost track of what the problem was then. You can pretty much
> do anything that's not illegal on a business connection.
I just get sick of the calls, and stop them early with two
questions:
1) Can I get static IPs?
2) Can I get a class-C subnet?
When they have to answer no to that, they leave until the next
call. It is quicker than trying to talk them down any other way.
>>> I know one guy locally who is constantly trying to get around this. I
>>> am surprised the ISP hasn't just terminated his service instead of playing
>>> hide-and-seek with his web server.
>>
>> Why not simply buy a business account as I did.
>
> Cause he's not a business and he doesn't want to pay the money. He's
> just a gamer and a wannabe hacker.
:-)
[ ... ]
>>> I have always been leary of these INTERNET Phone services. If your
>>> service goes out, how do you report it? You have to have some alternate
>>> phone service. Considering how seldom I even use my phone at home my
>>> next location may not have landline phone service at all. I carry one
>>> on my belt, why would I need another?
>>
>> This is not exactly an internet phone service. It is a fiber
>> optics feed which provides phone, cable, and internet through the same
>> fiber.
>
> Well, the way I understand it all you really get over the fiber is
> INTERNET. Everything else is delivered as IP services. VOIP and
> digital TV. The liklihood of the VOIP or TV going out n their own
> is slim, but if you loose INTERNET, you loose everything.
Yes -- except the cell phone -- which is usually out of hearing
when I'm in bed.
[ ... ]
>>> I used to work out of Rockville. I know VA pretty well, too. Used to
>>> go to the Pentagon, Arlington and Reston a lot. Many years ago, however.
>>
>> Today would have been a bad time for that. Any traffic between
>> VA and DC was shut down for most of the day. :-)
>
> Actually, I used to live in Gettysburg, PA and commute. If I had to be
> in VA early I used to go down 15 and come in from the west avoiding all
> the rush hour traffic. I actually found (and still find) it easier to
> get around down there than up here.
O.K. Good to know.
[ ... ]
>>>> I suspect so. Any chance of getting sufficient documentation
>>>> about the boards so you could write your own boot PROMs?
>>>
>>> Sure, I have all that. But it would be a lot easier if I had the MIKBUG
>>> PROM's as could then just use MIKBUG and download whatever code I was
>>> working on. Kinda like using ODT with either Kermit or VTServer.
>>
>> Hmm ... I never experience MIKBUG for the 68K systems, just for
>> the 6800. (Not even for the 6809.)
No clue what else it added -- other than expanded motorla hex
dump formats for larger words and address spaces. :-)
[ ... ]
>> I can understand that. I'm glad to already be retired, but
>> there is too much to move to go to someplace like South Texas, where I
>> grew up.
>
> I would love that. I always liked San Antonio. But my wifes only taste of
> Texas was Ft. Hood and now she won't go near the place. :-(
Even San Antonio would be a bit stronger military presence than
where I grew up -- about 90 miles south of San Antonio.
[ ... ]
>>> What you need is a real PDP-11 box!!
>>
>> Too big, too heavy. :-) And IIRC, DEC favored linear regulated
>> power supplies instead of switching supplies, which makes it even
>> heavier. :-)
>
> Ummmm... No. Ihave many desktop or pedestal PDP-11's. UNIBUS boxes were
> big, but not QBUS. And I wish they used real power supplies. A lot easier
> to repair.
O.K.
>>> As for RSTS, no hobbyist
>>> program for any of the non-Unix OSes. But, maybe someday.
>>
>> O.K. What OS is there likely to be for the LSI-11 then?
>
> BSD, early versions of UCSD-Pascal. And then ther eis the one I plan on
> writing when I get the time. :-)
O.K. is the BSD truly freely distributable? I though that the
PDP-11 BSD was still too full of AT&T code.
[ ... ]
>>> Pertec is the interface.
>>
>> Pertec was probably also once a maker, just as the "centronics"
>
> Yes, they were.
>
[ ... ]
>> With which OS? IIRC, this is one of the systems which OpenBSD
>> won't support because it requires a "blob" -- a chunk of pre-compiled
>> code from the vendor which can't be source code examined for security
>> holes and patched. Instead, you have to run it in your OS from within a
>> wrapper to make it look right to the OS. This is one of the reasons
>> that OpenBSD does not like linux -- too many linux distributions have
>> accepted the blob and the restrictive terms which come with it.
>
> I have used numerous hardware SCSI solutions with FreeBSD. I have a
> couple running right now. Bith SCSI and SATA.
But FreeBSD does not have the anti-blob stance that OpenBSD
does. One of the reasons why I trust OpenBSD more.
[ ... ]
[ ... ]
>>> Nope, still don't see a need for all them partitions. If I have a need
>>> for multiple partitions it is much better to use multiple drives.
>>
>> Perhaps if you were running a web server for multiple users, and
>> you wanted to be sure that one user could not hog space from another,
>> put each on his own partition. :-)
>
> Quotas takes care of that problem.
Yes -- with a greater overhead than rigid partitions would.
> More spindles also greatly increases throughput. Learned that running
> Usenet News Servers. :-)
Certainly -- but how much throughput will you *really* need for
about ten web servers on a small system?
[ ... ]
>>>>> Yes. Came from the same vendor as the M68K.
>>>>
>>>> So they did not like the Vendor? Nothing to do with the
>>>> hardware?
>>>
>>> It was not a matter of like or dislike as much as a matter of control or
>>> not control.
>>
>> Oh -- they could control what Intel did, but not Motorola.
>>
>
> Well, once they bought 65% of Intel's stock they could. :-)
Oh! And then they went to the PoowerPC -- from Motorola
originally, I believe.
thad.f...@gmail.com
> [...]
> > Every attempted
> > connection from a dial-up, DSL or Cable system is an ISP that does not
> > block port 25. If they actually did, we would not need RBLs'.
>
> I never said that they did block prot 25. It was *Thad* who
> said that. I know better.
Oh?
I defy you to find any ISP _today_ serving consumer accounts other
than a "Mom'n'Pop shop" ISP that does NOT block port 25 for non-
business accounts. Note: non-business accounts.
The highest Google hit match I've ever seen occurred just a moment ago
Googling "block port 25". Try it.
Port 587, for email injection, is allowed by the (same) ISPs as is
port 465 with SMTP authentication.
Even Sonic.net, the most respected ISP in Northern California and
Silicon Valley, blocks port 25; they have a good article about
this now common and almost ubiquitous practice here:
Bill Gunshannon
"DoN. Nichols" <dnic...@d-and-d.com> writes:
> On 2009-01-21, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>> In article <slrngnddtn....@katana.d-and-d.com>,
>> "DoN. Nichols" <dnic...@d-and-d.com> writes:
>>> On 2009-01-19, Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>>>> In article <slrngn7rab....@katana.d-and-d.com>,
>>>> "DoN. Nichols" <dnic...@d-and-d.com> writes:
>
> [ ... ]
>
>>>>>>>>>>> ceilidh!uunet!username@FQDN
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I keep trying to convince people that we really need to revive this email
>>>>>>>>>> system. It offers the best and quickest solution to the SPAM problem but
>>>>>>>>>> apparently I am the only one who can see that.
>
> Here is where I picked up that you wanted to revive bang paths,
You really need to get off this "bang-paths" thing. That's not UUCP. That's
an address notation intended to let humans visualize a network. I can show
you a similar map of the early ARPANET.
> and it was not until recently that I have decided that you did not. Had
> this been clear earlier, we could have saved a lot of words.
Hopefully, you can now see that the strength of this system, as regards
combating SPAM, is the necessary peering and using UUCP is only a medium,
already in existence and well tested, that supports this.
>
> [ ... ]
>
>>>>> How many MTAs automatically generate bang paths these days? And
>>>>> you would still need a massive database to generate the bang path.
>>>>
>>>> Yes, but pretty much all of them can (except maybe Exchange! :-) In today's
>>>> environment, the database would size would be trivial. 1TB disk : $129.00
>>>
>>> I not $127.00 for a SCSI or Fibre Channel version. :-(
>>
>> Of course not. It was another discussion but I still find it amazing that
>> SCSI disk prices have not come down like others. There is nothing new or
>> revolutionary in SCSI. What is keeping the prices up there?
>
> The SCSI and FC drives are a higher reliability construction
> than the IDE (and perhaps the SATA ones). The reliability does cost
> more -- either production costs or more extensive testing.
Also irrelevant today. Disks tend to be replaced with larger disks in
order to meet expanding space needs long before failure. I can not even
remember the last time I lost a system to a disk failure. (Actually, I can.
and it was environmental and would have affected SCSI just as badly as
it did the IDE's. AC failure. Room temp went above 100. Disk temps, in
their enclosures probably topped 150.)
>
> I got a batch of FC drives in Eurologic bays, and most of them
> showed up with over 50k hours on the clock -- 5.7 years. IDE drives
> tend to die a lot sooner.
I have IDE's here that have been running 24x7 for that long. I just checked,
one of my servers has been going 24x7 since July 2004. Interestingly enough,
I have had disks here where we had bot the IDE and the SCSI versions. A 340M
(yes, "M") Maxtor. The only difference in the two disks was the logic board.
The actual disk was exactly the same and even interchangeable. Hard to see
why one sold for $300 and the other sold for $2000.
>
>>>
>>> And there are still people who have dialup connections, and the
>>> download time for the updated maps would be a killer for them.
>>
>> The maps are for the MTA's, not the users. The user sends his message
>> using the same address syntax he does now. The MTA handles the routing.
>> That's what they're for and why we have MTA's. :-)
>
> O.K. Except that *I* am running MTAs, and I don't want to
> dedicate 1 TB of disk space to the task -- even if it were shared
> between the two MTAs.
Well, that's your choice. Another option I have been thinking about
lately would involve an alternate DNS-type system to handle this. But,
considering the cost ($120) and the liklihood that it would take nowhere
near a TB of diskspace, hard to see why you would have a problem with this.
>
>>>> The database would not change all that often except for minor additions
>>>> and deletions.
>>>
>>> How many end users change ISPs in the US per day? How about in
>>> the world. A bang path has to find its way to the user's machine, or
>>> the user's ISP's mail server. Since I run my own mail servers, I
>>> consider that it has to reach *my* machines.
>>
>> And? If I change ISP's what effect does that have on the MTA's? Forget
>> this "bang path" stuff. It is irrelevant.
>
> O.K. Now that it is clear that we are somehow using uucp
> without bang paths -- O.K.
Whew.... Finally. :-)
>
>> It was only in the very early
>> days of even UUCPNET that users actually had to supply the whole path
>> from one user to another. Start thinking of it just like IP. Your PC
>> does not know the route to every other machine in the world. All it has
>> to know is your address, the destination address and a next hop. Email,
>> using the UUCP method, can work exactly the same way. Stop thinking in
>> terms of UUCP as it was 40 years ago. I only suggest using UUCP because
>> it still exists, it is available on probably 95% of the machines running
>> as MTA's today and, it requires the one thing that is the basis for why
>> this method would be so much better than what we have today. Peering!
>
> The only problem that I see with this is that uucp is commented
> out in most systems these days (for security reasons).
Huh? Commented out? Actually, it is not installed by default any more on
BSD systems but it is still in the ports. ANd I can't even imagine what
"security reason" you might be thinking of. It is not installed in most
cases because no one is running it. :-) If there was a concern, it would
likely take less than a day to review all the UUCP software looking for
problems like buffer-overruns. But, remember one very important point.
UUCP never ran as root. So any exploit is not going to get one access to
a system.
> As a result, it
> has not received the level of scrutiny that even sendmail has -- and
> you know how long they have been reporting the "last security hole
> *ever* has just been plugged in sendmail". :-)
And the reason sendmail is still such a problem is that there are so many
people (and commercial implementations) that have deliberately chosen to
not run a modern fixed version. Personally, I stopped running sendmail
entirely based only on its complexity.
>
> I personally don't *trust* uucp as it sits.
Why? Give me an example of a threat you see?
>
>> The idea that there is an agreement between people exchanging email at
>> the MTA level so that there is a real way to guarantee that anti-social
>> behavior will not be tolerated.
>
> O.K. That I can see.
>
>>>
>>>> One could even apply SPF algorithms so that the problem
>>>> of the disappearing link (something else that while rather common in the
>>>> old days would be very unlikely today) would not eb there either.
>>>
>>> How do you intend to make this work? What does your bang-path
>>> look like as you plan the new system?
>>
>> Who cares what the bang paths look like? What does the traceroute from
>> you to me look like? You don't know and you (probably) don't care. It
>> is irrelevant.
>
> Actually -- I often use traceroute to see what the path between
> my systems and some others happens to be at the moment -- trying to
> figure out what is causing the system to be unreachable or very slow.
> So I *do* care from time to time. :-)
So do I, sometimes. Just did yesterday and for the first time in all my
years of doing this I saw "!X" in a traceroute. Look that one up!! :-)
But, again, traceroute is of very limited use today. It is blocked at the
firewall of a lot of places specifically because they don't want outsiders
mapping their network. So, the results tend be of very dubious value. And
that doesn't even take into account the very nature of IP which does not
guarantee that an two packets will take the same path. Remember that
traceroute uses a feature of IP for something that it was not intended for.
>
> Since it is clear that we are keeping FQDNs, I'll snip a lot of
> this out.
>
> [ ... ]
>
>> UUCP: {philabs}\
>> {phri } >!trotter.usma.edu!bill |
>> {sunybcs}/
>>
>> Note the "machine name" immediately before my username. That was 30 years
>> ago and we already were using domain qualified names in UUCP.
>
> My 3B1s did not understand FQDNs, and just treated them as
> another string which was a system name. It was up to uunet to deal with
> the domain name itself.
As could any UUCP machine. But, again, let's live in the 21st century. How
many real, serious MTA's are going to be running 3B1's? Not that they could
not function as endnodes, but you are just not going to find one in the
middle of the network.
>
> (Actually, most of them *did* understand FQDNs, because I had
> several ethernet cards for them, and the WillGoWrong TCP/IP package. :-)
Again, it ws not running IP that gave them that capability, it was the
MTA software. Sendmail was capable of looking at the address and deciding
which transport to use. That was what it was written for. Old sendmail.cf
files make for real interesting reading. There used to be a lot more than
even TCP/IP and UUCP as far as email transport went.
>
> [ ... ]
>
>>> If one system goes down, *news* gets there via other paths, but
>>> email bang paths die at the dead system,
>>
>> Why does that have to happen?
>
> Because I was assuming traditional bang paths. Now I am not.
>
> [ ... ]
>
>>> because they are not broadcast
>>> to all known connections. You don't *want* something addressed to an
>>> individual to be broadcast all over the world. :-)
>>
>> Once again, look at the IP model. Packets are not "broadcast" to every
>> router in the world. The are sent to the next hop. And, in most cases,
>> if a hop disappears they are routed around it.
>
> Yes -- it is slower to come back on line, but it does eventually
> get there.
And with the very nature of email, these delays would not even be noticed.
>
>> Why is it so hard to imagine
>> email doing the same thing?
>
> Because I was fixated on the bang path, which had all the
> machine names hard-coded in it, and no provision for updating on the
> fly.
>
>>>
>>>> it is unlikely any major player would
>>>> have a single connection making routing around failures easy.
>>>
>>> You're assuming that there will only be major players in the
>>> game.
>>
>> There will only be major players in the game. The whole idea of this is
>> to get Joe User and hos zombied PC out of the picture.
>
> I want *him* out of it -- but I don't want to be shut out of
> running my own MTAs.
No reason why you would be. All you need to do is find someone who is
willing to trust you enough to sign a peering agreement with you. And
then, of course, you have to live up to the agreement. Because the
system does not limit you to someone you can afford to call on the phone,
like it used to be, finding a peer should not be a problem. Unless, of
course, you have a reputation as a SPAMer. :-)
>
>>> Bang paths often went through a number of other small systems
>>> before they got to a backbone system. At first, my outgoing email was:
>>>
>>> dnichols@ceilidh!beartrack!uunet!username@FQDN
>>
>> And, why was that? Probably because you ahd to connect to the nearest
>> (cost-wise, not distance-wise) system to you. Why did you not contact
>> UUNET directly?
>
> Because I wanted to get the bugs out of the setup (configuration
> of UUCP, etc) *before* I started paying money to uunet. And I had a
> friend at the other end. Physically, it was from me in VA to Maryland,
> and then back to uunet in Virginia not too far away. :-)
OK, interesting. I always remember a car dealership in Towanda, PA that
was on UUCP.net. That is real hick-town Pennsylvania. This site was
paying the toll charges to call Cornell U. Not only inter-LATA but also
accross a stateline. Not a cheap call in those days. Turned out Jr.
had gone off to college and got hooked on News and Email. When he came
home and joined the family business he needed his fix. So, he got a
Tandy 6000 running XENIX and joined the net!! Those were the days.
>
>> I know why I wouldn't have. :-) But today, everybody
>> can connect directly to everybody else. That's how SMTP works. All I
>> am trying to do is put a social layer between the technical method and
>> the user because SPAM is a social problem and can not be solved with a
>> contrived technical solution. We don't have to use UUCP to do this.
>> A whole new Email system could be devised that would provide this. How
>> long you think that would take? What do you think the acceptance rate
>> would be? I am only suggesting using UUCP because it already exists,
>> we know it works and it solves the problem.
>
> But we don't know about its security in the face of modern
> attacks. I have *never* allowed a uucp connection to/from my systems
> via the internet.
As I said, none of it ran as root so any holes would be of little value.
And, the system is really rather simple and could easily be examined in
a day. But let's consider reality. It is still a part of the current
FreeBSD ports tree. That's a relatively safe bet that it has been seeing
maintenance even after all these years. As a minimum, someone is taking
the time to ensure that it still works with each new release of FreeBSD.
Considering the holes in things like telnetd and the Berkely R-commands that
people run every day, (or even SSH v.1 for that matter) I think this poses
a minimal risk and any real risk is likely to be removed before it grew
big enough to attract any major attackers.
>
> And this puts more passwords out there for people to try to
> crack, either by brute force, or by capturing /etc/shadow and running
> crack or jack-the-ripper against it.
Well, one has to assume we are all running shadow passwords at this point
so that makes that a minimal problem. And, wha tdo they get if the get a
password? Their shell is not a shell at all. It is a program that only
talks to one machine and runs the uucp protocol. There are much bigger
fish for the hackers to fry.
>
> Granted, I believe that I have good secure passwords, but with a
> uucp port open, I would never be sure who might have gotten a copy to
> attack.
How would they get a copy of that without also getting a copy of the
password for root? Especially when you figure (I haven't tried this yet,
the ide just popped into my head) you can probably run your UUCP over SSH
adding encryption to the game.
Ummm.... No. I specifically said the way IP does it. My example of
News was merely because both News and Email are store-and-forward and
both had their roots in UUCP. News has not changed the way it does
things, really, just the transport medium. I am saying that the same
could be done with email giving an additional control that is the specific
control needed to clean things up.
>
> [ ... ]
>
>>>> And once you eliminate the SPAM and other anti-social
>>>> practices the system becomes almost maintenance free. Certainly a lot less
>>>> maintenance than it takes to run a decent MTA today.
>>>
>>> IIRC, bang paths took a lot of maintenance.
>>
>> Well, I ran UUCP machines. Trust me, trying to keep up with all the
>> new and constantly eveolving SPAM methods takes a lot more maintenance.
>
> That is maintenance in a different field -- filtering instead of
> connectivity. :-)
Where the time is spent is irrelevant. It is my time that is being wasted.
Trying to keep up with the SPAMers is taking a lot more time than running
UUCP ever did.
>
>> And, is doomed to failure. Worse still, it fails in two differnt ways.
>> One is that you still get SPAM and the other is that you don't get
>> legitimate emails and may never know that you didn't get it.
>
> Certainly.
>
> [ ... ]
>
>>> If so,
>>> how do you keep the spamers from figuring out how to manipulate *that*
>>> system as well?
>>
>> Let's see, I have an MTA. I agree to exchange email with you. We have
>> a signed agreement that says I will not let my users send SPAM. What
>> do you think happens if I decide to let one of my users send SPAM? You
>> pull the plug and possibly seek civil redress for breach of contract
>> with me. No one can play (at the level of the MTA) without an existing
>> peering agreement with some other MTA who is a part of the network. No
>> zombied PC's. No just setting up a machine on the INTERNET and blasting
>> out SPAM to any MTA you can connect to on port 25. If yo are not in my
>> L.sys file I don't talk to you. Period.
>
> And -- if the spamers find out how to impersonate systems which
> *are* in your L.sys file, they can talk to you and spew spam out from
> *your* system, thus getting you disconnected from the world.
If set up properly that would be virtually impossible. Remember, we have
a number of greater levels of security than we had before. They need as
a minimum: The System name as it appears in the L.sys file, the userid and
the password. But, we are running this over IP so now we also add an ACL
to our firewall which only lets machines with the right IP Address connect
to the UUCP service. Still think you can get into my system?
>
> [ ... ]
>
>> No, just because it used to work that way doesn't mean it has to be that
>> way. One machine need only know the next hop.
>>
>>> *This* is what would make tracking spam back easier.
>>
>> In my system, SPAM becomes a one time occurance, if at all. Think of the
>> result of sending SPAM as the Amish custom called shunning. :-)
>
> O.K.
>
> [ ... ]
>
>>>>> And IIRC, uucp required that there be no two systems with
>>>>> the same name -- making a naming problem with the number of machines in
>>>>> use today.
>>>>
>>>> Same thing exists now. There can not be another cs.uofs.edu anywhere
>>>> on the INTERNET. So, what's the problem? Or are you assuming we would
>>>> still be stuck with single word names of no more than 8 characters?
>>>
>>> You have a FQDN there, not just a system name. Your system name
>>> is 'cs', and how many 'cs' machines are there at colleges around the
>>> country?
>>
>> Actually, no it's not. Machine name is mailhost. You are once again
>> confusing an email address with a machine name. They are not the same.
>
> O.K. But the *original* bang paths used machine names
> exclusively.
Ummm.... No. trotter.usma.edu!bill
Maybe in the very early days, but later. Like everything else, it morphed
to meet needs and adapt to a changing and growing network.
>
> [ ... ]
>
>>>>> The example which I showed above only used uucp to get to uunet.
>>>>> From there, things went by domain name.
>>>>
>>>> Yes, and many of those machines connected by domain name were UUCP
>>>> machines. Look at the example I posted earlier of what my address
>>>> was.
>>>> trotter.usma.edu!bill
>>>>
>>>> There's a three part domain style name used in a bag path. yes, it worked
>>>> just fine.
>>>
>>> But it required a system which understood FQDNs.
>>
>> Name one today that doesn't?
>
> My 3B1s if I don't install TCP/IP and ethernet cards. :-)
Expecting your 3B1 to be taken seriously in today's networks is just
plain silly. The fact is, it could play, but only with the help of
others. But that is a shortcoming of the 3B1 and not the protocol.
Especially when you take into consideration taht if you really wanted
a 3B1 to be a part of a modern network the answer is to run modern
software. What UUCP are you running? AT&T? Ever look at Honey-Danber?
That dates back to at least the 80's and was a great imporvement. I
don't know what it would take to port one of the current uucp's to a
3B1 but knowing how truly simple the actual software is, I would imagine
it was doable. And then with sendmail or postfix as a frontend you get
to play just like everybody else. Of course, the real problem is that
the 3B1 only has a serial connection. Oh wait, that simplifies all of
it!! If you only have a serial connection you are probably going to have
to just punt any email it generates to soemone else. And then he can
handle the address resolution. Hmmm.... Problem solved.
I would trust uucp a lot more than I would trust telnetd and everybody runs
that!! And, if you are going to be that paranoid, you probably should never
read Ken Thompson's "On trusting trust". :-)
On a particular architecture VMS has always maintained forward compatability.
That is programs from VAX VMS 5.5 could be run on VAX VMS 7.2. For obvious
reasons the reverse is not true and has never been for anyone.
I just hang up when they identify themselves (or sooner if they refuse to
identify themselves.) People think I am just rude, but my time costs money
and I am not willing to give it to anyone for free.
Good thing it wasn't 100 miles south of San Antonio. :-)
>
> [ ... ]
>
>>>> What you need is a real PDP-11 box!!
>>>
>>> Too big, too heavy. :-) And IIRC, DEC favored linear regulated
>>> power supplies instead of switching supplies, which makes it even
>>> heavier. :-)
>>
>> Ummmm... No. Ihave many desktop or pedestal PDP-11's. UNIBUS boxes were
>> big, but not QBUS. And I wish they used real power supplies. A lot easier
>> to repair.
>
> O.K.
>
>>>> As for RSTS, no hobbyist
>>>> program for any of the non-Unix OSes. But, maybe someday.
>>>
>>> O.K. What OS is there likely to be for the LSI-11 then?
>>
>> BSD, early versions of UCSD-Pascal. And then ther eis the one I plan on
>> writing when I get the time. :-)
>
> O.K. is the BSD truly freely distributable? I though that the
> PDP-11 BSD was still too full of AT&T code.
Could be, but the holder of the Unix license has specifically released it
for use. It is still being maintained and a new patch was just released
a week or so ago.
There has never been a PowerPC based PC. That was always another
niche product, just like the M68K systems they made before the PC
and continued to make and sell after they started doing PC's. It's
all about target markets. IBM knew how to do that, which is why,
after all their problems, they are still there and still holding a
major part of many markets.
Bill Gunshannon
thad.f...@gmail.com writes:
> On Jan 21, 10:39 pm, "DoN. Nichols" <dnich...@d-and-d.com> wrote:
>> [...]
>> > Every attempted
>> > connection from a dial-up, DSL or Cable system is an ISP that does not
>> > block port 25. If they actually did, we would not need RBLs'.
>>
>> I never said that they did block prot 25. It was *Thad* who
>> said that. I know better.
>
> Oh?
>
> I defy you to find any ISP _today_ serving consumer accounts other
> than a "Mom'n'Pop shop" ISP that does NOT block port 25 for non-
> business accounts. Note: non-business accounts.
From the current logs on my email server:
pool-71-244-121-91.albyny.fios.verizon.net (Verizon FIOS in Albany, NY)
pool-173-73-118-217.washdc.fios.verizon.net (Verizon FIOS in Washington, DC)
c-71-234-82-0.hsd1.ct.comcast.net (Comcast Connecticut DHCP Pool)
Want more? That's just the ones I cold find quick because I know they
are in there.
>
> The highest Google hit match I've ever seen occurred just a moment ago
> Googling "block port 25". Try it.
Google, yeah, there's a real authority. The site responible for 90%
of the USENET SPAM.
>
> Port 587, for email injection, is allowed by the (same) ISPs as is
> port 465 with SMTP authentication.
>
> Even Sonic.net, the most respected ISP in Northern California and
> Silicon Valley, blocks port 25; they have a good article about
> this now common and almost ubiquitous practice here:
Nobody said none of them do. But many of the major players do not.
I am on Verizon at home, I will try it tonight but I have no doubt
it will work.
thad.f...@gmail.com
> an address notation intended to let humans visualize a network. I can show
> you a similar map of the early ARPANET.
That'd be interesting. I began using the ARPANET since it was
first setup and the only maps I ever saw were graphic ones from
BBN like this:
Bill Gunshannon
Wow!!! Does that bring back memories..... I haven't seen that map in
more than 2 decades. But I was thinking of the ASCII maps when the
ARPANET was only a dozen or so sites. :-) It was already big by the
time that map was made. :-) Actually, I guess "map" is kind of more
than it deserves. It was a list of machines vaguely representing where
they were located in relation to each other with lines connecting them.
DoN. Nichols
> On Jan 21, 10:39 pm, "DoN. Nichols" <dnich...@d-and-d.com> wrote:
>> [...]
>> > Every attempted
>> > connection from a dial-up, DSL or Cable system is an ISP that does not
>> > block port 25. If they actually did, we would not need RBLs'.
>>
>> said that. I know better.
>
> Oh?
>
> I defy you to find any ISP _today_ serving consumer accounts other
> than a "Mom'n'Pop shop" ISP that does NOT block port 25 for non-
> business accounts. Note: non-business accounts.
From my logs (numbers preceding each are the number of times
each has tried to deliver to my port 25. I've snipped out all which
just showed up as raw IPs, as well as ones which showed up with names
which indicated that they were actually mail servers of some sort.
======================================================================
1 36.89.221.62.dyn.idknet.com
1 63-228-198-248.slkc.qwest.net
1 68-116-113-140.dhcp.mdfd.or.charter.com
1 77-23-156-162-dynip.superkabel.de
1 82-169-130-155.ip.telfort.nl
1 91-66-63-102-dynip.superkabel.de
1 91-67-188-62-dynip.superkabel.de
1 a83-132-237-122.cpe.netcabo.pt
1 adsl-70-136-75-88.dsl.rcsntx.swbell.net
1 apn-89-223-168-160.vodafone.hu
1 athedsl-4511212.home.otenet.gr
1 bl6-18-90.dsl.telepac.pt
1 c122091.upc-c.chello.nl
1 catv3EC95DB7.pool.t-online.hu
1 chello080109133121.tirol.surfer.at
1 cpe-098-026-033-230.nc.res.rr.com
1 cpe-69-206-232-111.hvc.res.rr.com
1 d-24-245-111-229.cpe.metrocast.net
1 f054017063.adsl.alicedsl.de
1 frnk-4d00f07e.pool.mediaWays.net
1 h94-75-2-22.ufamts.ru
1 h94-75-56-51.ufamts.ru
1 host-52-151.compi.net.pl
1 HSI-KBW-078-042-130-013.hsi3.kabel-badenwuerttemberg.de
1 HSI-KBW-082-212-033-192.hsi.kabelbw.de
1 ljslo-41-126-13.adsl.softnet.si
1 mm-188-254-57-86.leased.line.mgts.by
1 p50870B4E.dip0.t-ipconnect.de
1 pool-04002.externet.hu
1 pool-064ce.externet.hu
1 ppp-124-122-152-72.revip2.asianet.co.th
2 0x57304159.sdbnxx2.dynamic.dsl.tele.dk
2 114-44-12-112.dynamic.hinet.net
2 118-165-75-109.dynamic.hinet.net
2 122-118-75-109.dynamic.hinet.net
2 125-223.104-92.cust.bluewin.ch
2 187-25-163-126.3g.claro.net.br
2 202-71-90-178.ap-w01.canvas.ne.jp
2 24-181-103-175.dhcp.leds.al.charter.com
2 65.sub-75-212-137.myvzw.com
2 68-117-199-98.dhcp.ftgn.ga.charter.com
2 68.136.broadband3.iol.cz
2 82-208-86-209.dynamic.mts-nn.ru
2 82-33-43-229.cable.ubr04.stav.blueyonder.co.uk
2 84-252-6-9.2073171606.ddns-lan.ekk.bg
2 85.136.172.39.dyn.user.ono.com
2 86-63-64-82.sta.asta-net.com.pl
2 93-181-223-196.adsl.yaroslavl.ru
2 bb219-75-110-158.singnet.com.sg
2 c-71-199-184-142.hsd1.ga.comcast.net
2 c-76-109-198-216.hsd1.fl.comcast.net
2 cable-89-216-126-39.static.sbb.rs
2 catv3EC948D2.pool.t-online.hu
2 cE55DBF51.dhcp.bluecom.no
2 cp1377658-a.venlo1.lb.home.nl
2 cpe-075-176-054-022.carolina.res.rr.com
2 cpe-098-025-254-140.sc.res.rr.com
2 cpe-24-161-223-88.bak.res.rr.com
2 dslb-082-083-230-201.pools.arcor-ip.net
2 e181160107.adsl.alicedsl.de
2 f051173215.adsl.alicedsl.de
2 h111.168.140.67.dynamic.ip.windstream.net
2 homeuser77.43.175.36.ccl.perm.ru
2 host-85-237-63-92.dsl.sura.ru
2 host-88-132-30-70.prtelecom.hu
2 i117101.upc-i.chello.nl
2 node-3811.tor.pppoe.execulink.com
2 p579F4EB0.dip.t-dialin.net
2 pool-173-51-87-139.lsanca.fios.verizon.net
2 pool-70-110-22-239.washdc.fios.verizon.net
2 pool-71-109-43-90.lsanca.dsl-w.verizon.net
2 pool-71-245-217-233.delv.east.verizon.net
2 pool-96-253-164-89.ptldor.fios.verizon.net
2 ppp-124-122-207-52.revip2.asianet.co.th
2 VDSL-130-13-18-194.PHNX.QWEST.NET
3 212-178-11-170.broadband.tenet.odessa.ua
3 80-235-153-57.cable.ubr23.newt.blueyonder.co.uk
3 adsl-70-128-63-86.dsl.ltrkar.swbell.net
3 apn-77-115-48-123.gprs.plus.pl
3 d36-91-130.home1.cgocable.net
3 host-93-124-94-11.dsl.sura.ru
3 MS-140-123.dyn-ip.SPb.SkyLink.RU
3 oh-65-41-207-10.sta.embarqhsd.net
3 xdsl-81-173-189-242.netcologne.de
4 118-165-76-182.dynamic.hinet.net
4 118-165-91-115.dynamic.hinet.net
4 174-145-157-21.pools.spcsdns.net
4 65.179.33.65.cfl.res.rr.com
4 68-29-133-181.pools.spcsdns.net
4 74-128-199-154.dhcp.insightbb.com
4 77.79.154.244.dynamic.ufanet.ru
4 adsl-64-237-241-39.prtc.net
4 c-71-204-157-151.hsd1.ca.comcast.net
4 c-76-118-228-27.hsd1.ma.comcast.net
4 cp1339768-a.tilbu1.nb.home.nl
4 cpe-74-64-107-44.nyc.res.rr.com
4 cpe-74-71-58-36.twcny.res.rr.com
4 dsl-242-174-216.telkomadsl.co.za
4 host-64-179-16-181.spr.choiceone.net
4 host81-137-213-100.in-addr.btopenworld.com
4 host81-149-238-133.in-addr.btopenworld.com
4 ppp-94-68-139-67.home.otenet.gr
4 vms173003pub.verizon.net
5 118-165-85-193.dynamic.hinet.net
5 187-25-96-125.3g.claro.net.br
5 24-176-145-153.dhcp.kgpt.tn.charter.com
5 92-235-116-202.cable.ubr10.dudl.blueyonder.co.uk
5 pa9-84-91-206-17.netvisao.pt
5 wsip-68-15-53-45.ri.ri.cox.net
6 144.93.221.62.dyn.idknet.com
6 77-20-18-58-dynip.superkabel.de
6 84-105-53-137.cable.quicknet.nl
6 85-132-219-165-eth2-gwfm7-user.802.cz
6 89-232-224-224.pppoe-adsl.isurgut.ru
6 adsl-8-107.teol.net
6 c-71-192-123-14.hsd1.ma.comcast.net
6 host86-156-233-84.range86-156.btcentralplus.com
6 pool-71-110-178-195.lsanca.dsl-w.verizon.net
6 ppp-38-41.telesat.com.co
6 ppp079166076070.dsl.hol.gr
6 static-68-236-178-2.ny325.east.verizon.net
6 static-host210-2-166-68.link.net.pk
6 VDSL-130-13-157-22.PHNX.QWEST.NET
7 ppp-70-255-168-210.dsl.snantx.swbell.net
11 host86-131-207-28.range86-131.btcentralplus.com
13 195-5-179-248.altanusprivatemedia.com
27 66-29-255-66.ds1-static.mia1.net.ststelecom.com
107 cpc3-ayle2-0-0-cust101.watf.cable.ntl.com
123 c-98-213-119-105.hsd1.il.comcast.net
======================================================================
Now -- granted, a lot of these are out-of-country, but there are
sufficient sampled from:
charter.com
choiceone.net
comcast.net
dynamic.ip.windstream.net
hinet.net
insightbb.com
qwest.net
rr.com (in particular, res.rr.com -- the residential addresses,
not the business ones)
swbell.net
t-dialin.net
verizon.net
> The highest Google hit match I've ever seen occurred just a moment ago
> Googling "block port 25". Try it.
You are believing what Google tells you. I'm believing what
actually hits my mail servers -- even from IPSs who claim to be blocking
port 25.
> Port 587, for email injection, is allowed by the (same) ISPs as is
> port 465 with SMTP authentication.
>
> Even Sonic.net, the most respected ISP in Northern California and
> Silicon Valley, blocks port 25; they have a good article about
> this now common and almost ubiquitous practice here:
>
><http://www.sonic.net/support/faq/advanced/port_25.shtml>
So -- how about comcast, charter, quest, swbell, and verizon?
DoN. Nichols
"header has gotten larger than jove wants to handle, so I've trimmed it
down significantly.
[ ... ]
> >> Of course not. It was another discussion but I still find it amazing that
> >> SCSI disk prices have not come down like others. There is nothing new or
> >> revolutionary in SCSI. What is keeping the prices up there?
> >
> > The SCSI and FC drives are a higher reliability construction
> > than the IDE (and perhaps the SATA ones). The reliability does cost
> > more -- either production costs or more extensive testing.
>
> Also irrelevant today. Disks tend to be replaced with larger disks in
> order to meet expanding space needs long before failure.
Not in my case. :-) I get batches of disks from hamfests and
continue to use them. :-)
I don't have the money to buy *new* disks in the quantities
which I would like. :-)
> I can not even
> remember the last time I lost a system to a disk failure. (Actually, I can.
> and it was environmental and would have affected SCSI just as badly as
> it did the IDE's. AC failure. Room temp went above 100. Disk temps, in
> their enclosures probably topped 150.)
That can do it. I had a similar problem take out a Sun LX
(which was running near the top of a rack, and thus hotter than most
other systems. It took out the CPU, not the disk FWIW. I was able to
put the same disk in a spare LX and continue operation after the AC was
working again.
> >
> > I got a batch of FC drives in Eurologic bays, and most of them
> > showed up with over 50k hours on the clock -- 5.7 years. IDE drives
> > tend to die a lot sooner.
>
> I have IDE's here that have been running 24x7 for that long. I just checked,
> one of my servers has been going 24x7 since July 2004. Interestingly enough,
How many of the disks at once? These were four arrays of seven
36 GB disks each as received.
> I have had disks here where we had bot the IDE and the SCSI versions. A 340M
> (yes, "M") Maxtor. The only difference in the two disks was the logic board.
> The actual disk was exactly the same and even interchangeable. Hard to see
> why one sold for $300 and the other sold for $2000.
They can get people to pay that for the SCSI ones? :-)
But (most of) my systems *can't* run IDE drives, even if I
wanted to.
> >>> And there are still people who have dialup connections, and the
> >>> download time for the updated maps would be a killer for them.
> >>
> >> The maps are for the MTA's, not the users. The user sends his message
> >> using the same address syntax he does now. The MTA handles the routing.
> >> That's what they're for and why we have MTA's. :-)
> >
> > O.K. Except that *I* am running MTAs, and I don't want to
> > dedicate 1 TB of disk space to the task -- even if it were shared
> > between the two MTAs.
>
> Well, that's your choice. Another option I have been thinking about
> lately would involve an alternate DNS-type system to handle this. But,
> considering the cost ($120)
The cost is that low *if* you are running a system which can
handle the IDEs.
[ ... ]
> > O.K. Now that it is clear that we are somehow using uucp
> > without bang paths -- O.K.
>
> Whew.... Finally. :-)
[ ... ]
> > The only problem that I see with this is that uucp is commented
> > out in most systems these days (for security reasons).
>
> Huh? Commented out? Actually, it is not installed by default any more on
> BSD systems but it is still in the ports.
Huh?
Solaris 2.6 Installed
Solaris 10 Installed
OpenBSD 3.9 Installed
OpenBSD 4.2 Installed
All commented out in /etc/inetd.conf or equivalent, but can be
enabled at a moment's notice.
Your BSD is not the same as mine, apparently. :-)
> ANd I can't even imagine what
> "security reason" you might be thinking of. It is not installed in most
> cases because no one is running it. :-) If there was a concern, it would
> likely take less than a day to review all the UUCP software looking for
> problems like buffer-overruns. But, remember one very important point.
> UUCP never ran as root. So any exploit is not going to get one access to
> a system.
A lot of linux systems want to install everything on one big
partition, and have swap as the only other one.
This makes files vulnerable to copying -- or even replacing --
by a symlink into the uucp buffer directory.
I tend to prefer a lot of separate partitions, to protect
against this sort of trick.
> > As a result, it
> > has not received the level of scrutiny that even sendmail has -- and
> > you know how long they have been reporting the "last security hole
> > *ever* has just been plugged in sendmail". :-)
>
> And the reason sendmail is still such a problem is that there are so many
> people (and commercial implementations) that have deliberately chosen to
> not run a modern fixed version. Personally, I stopped running sendmail
> entirely based only on its complexity.
As did I -- many years ago. And that complexity makes it more
difficult to audit for security holes, since it (at least used to) run
as root.
> >
> > I personally don't *trust* uucp as it sits.
>
> Why? Give me an example of a threat you see?
Until it gets used regularly enough so people start finding the
new security holes which are present.
[ ... ]
> > Actually -- I often use traceroute to see what the path between
> > my systems and some others happens to be at the moment -- trying to
> > figure out what is causing the system to be unreachable or very slow.
> > So I *do* care from time to time. :-)
>
> So do I, sometimes. Just did yesterday and for the first time in all my
> years of doing this I saw "!X" in a traceroute. Look that one up!! :-)
> But, again, traceroute is of very limited use today. It is blocked at the
> firewall of a lot of places specifically because they don't want outsiders
> mapping their network. So, the results tend be of very dubious value. And
> that doesn't even take into account the very nature of IP which does not
> guarantee that an two packets will take the same path. Remember that
> traceroute uses a feature of IP for something that it was not intended for.
But it still is a useful tool.
[ ... ]
> > My 3B1s did not understand FQDNs, and just treated them as
> > another string which was a system name. It was up to uunet to deal with
> > the domain name itself.
>
> As could any UUCP machine. But, again, let's live in the 21st century. How
> many real, serious MTA's are going to be running 3B1's? Not that they could
> not function as endnodes, but you are just not going to find one in the
> middle of the network.
A very *small* network? :-)
> >
> > (Actually, most of them *did* understand FQDNs, because I had
> > several ethernet cards for them, and the WillGoWrong TCP/IP package. :-)
>
> Again, it ws not running IP that gave them that capability, it was the
> MTA software.
Running TCP/IP allowed them to know what to do with the FQDN,
instead of just passing it on to a system upstream in the hopes that it
would understand what to do with it.
> Sendmail was capable of looking at the address and deciding
> which transport to use. That was what it was written for. Old sendmail.cf
> files make for real interesting reading.
Indeed so -- and another reason that I am glad to not use
sendmail. :-)
> There used to be a lot more than
> even TCP/IP and UUCP as far as email transport went.
Sure. I'm not sure how many transport protocols "mh" used, but
quite a few, I think.
[ ... ]
> >> Once again, look at the IP model. Packets are not "broadcast" to every
> >> router in the world. The are sent to the next hop. And, in most cases,
> >> if a hop disappears they are routed around it.
> >
> > Yes -- it is slower to come back on line, but it does eventually
> > get there.
>
> And with the very nature of email, these delays would not even be noticed.
Except when you are waiting for a password being e-mailed to
give you access to a web site. :-)
[ ... ]
> >> There will only be major players in the game. The whole idea of this is
> >> to get Joe User and hos zombied PC out of the picture.
> >
> > I want *him* out of it -- but I don't want to be shut out of
> > running my own MTAs.
>
> No reason why you would be. All you need to do is find someone who is
> willing to trust you enough to sign a peering agreement with you. And
> then, of course, you have to live up to the agreement. Because the
> system does not limit you to someone you can afford to call on the phone,
> like it used to be, finding a peer should not be a problem. Unless, of
> course, you have a reputation as a SPAMer. :-)
Only because some spamer in Russia about once a year does a
major spam run with gazillions of faked usernames at my domain name. I
had to set up automatic throttling on my MTAs -- load average over four
and the SMTP port is slammed shut until the load average falls back from
processing what had been swallowed. (Using Bayesian filtering adds to
the load, of course.)
[ ... ]
> >>> Bang paths often went through a number of other small systems
> >>> before they got to a backbone system. At first, my outgoing email was:
> >>>
> >>> dnichols@ceilidh!beartrack!uunet!username@FQDN
> >>
> >> And, why was that? Probably because you ahd to connect to the nearest
> >> (cost-wise, not distance-wise) system to you. Why did you not contact
> >> UUNET directly?
> >
> > Because I wanted to get the bugs out of the setup (configuration
> > of UUCP, etc) *before* I started paying money to uunet. And I had a
> > friend at the other end. Physically, it was from me in VA to Maryland,
> > and then back to uunet in Virginia not too far away. :-)
>
> OK, interesting. I always remember a car dealership in Towanda, PA that
> was on UUCP.net. That is real hick-town Pennsylvania. This site was
> paying the toll charges to call Cornell U. Not only inter-LATA but also
> accross a stateline. Not a cheap call in those days. Turned out Jr.
> had gone off to college and got hooked on News and Email. When he came
> home and joined the family business he needed his fix. So, he got a
> Tandy 6000 running XENIX and joined the net!! Those were the days.
:-)
> >> I know why I wouldn't have. :-) But today, everybody
> >> can connect directly to everybody else. That's how SMTP works. All I
> >> am trying to do is put a social layer between the technical method and
> >> the user because SPAM is a social problem and can not be solved with a
> >> contrived technical solution. We don't have to use UUCP to do this.
> >> A whole new Email system could be devised that would provide this. How
> >> long you think that would take? What do you think the acceptance rate
> >> would be? I am only suggesting using UUCP because it already exists,
> >> we know it works and it solves the problem.
> >
> > But we don't know about its security in the face of modern
> > attacks. I have *never* allowed a uucp connection to/from my systems
> > via the internet.
>
> As I said, none of it ran as root so any holes would be of little value.
> And, the system is really rather simple and could easily be examined in
> a day. But let's consider reality. It is still a part of the current
> FreeBSD ports tree.
It is installed (but not enabled by default) in OpenBSD. This
gives me a bit more trust than just being in the ports tree. If it is
*installed* in OpenBSD, that means that they have done a thorough
examination of the code.
> That's a relatively safe bet that it has been seeing
> maintenance even after all these years. As a minimum, someone is taking
> the time to ensure that it still works with each new release of FreeBSD.
> Considering the holes in things like telnetd and the Berkely R-commands that
> people run every day,
I don't. (except temporarily on the inside net to talk to my
SGI Indigo 2 until I can get SSH running in it. And no machine from the
outside is allowed to talk to it.
Nor is ftp enabled by default in my systems.
> (or even SSH v.1 for that matter) I think this poses
> a minimal risk and any real risk is likely to be removed before it grew
> big enough to attract any major attackers.
Hmm ... given that the passwords for uucp pass over the net in
the clear, both the username and the password could be easily captured.
> > And this puts more passwords out there for people to try to
> > crack, either by brute force, or by capturing /etc/shadow and running
> > crack or jack-the-ripper against it.
>
> Well, one has to assume we are all running shadow passwords at this point
> so that makes that a minimal problem. And, wha tdo they get if the get a
> password? Their shell is not a shell at all. It is a program that only
> talks to one machine and runs the uucp protocol. There are much bigger
> fish for the hackers to fry.
If they do get a name and a password, they can inject spam in
the feed from *my* systems, and give me the blame.
One of many reasons why I don't allow a Windows box to touch the
outside via my net.
> > Granted, I believe that I have good secure passwords, but with a
> > uucp port open, I would never be sure who might have gotten a copy to
> > attack.
>
> How would they get a copy of that without also getting a copy of the
> password for root? Especially when you figure (I haven't tried this yet,
> the ide just popped into my head) you can probably run your UUCP over SSH
> adding encryption to the game.
The UUCP over SSH sounds better.
[ ... ]
> >>> IIRC, bang paths took a lot of maintenance.
> >>
> >> Well, I ran UUCP machines. Trust me, trying to keep up with all the
> >> new and constantly eveolving SPAM methods takes a lot more maintenance.
> >
> > That is maintenance in a different field -- filtering instead of
> > connectivity. :-)
>
> Where the time is spent is irrelevant. It is my time that is being wasted.
> Trying to keep up with the SPAMers is taking a lot more time than running
> UUCP ever did.
Well ... UUCP had a lot less connectivity than SMTP does today. :-)
[ ... ]
> > And -- if the spamers find out how to impersonate systems which
> > *are* in your L.sys file, they can talk to you and spew spam out from
> > *your* system, thus getting you disconnected from the world.
>
> If set up properly that would be virtually impossible. Remember, we have
> a number of greater levels of security than we had before. They need as
> a minimum: The System name as it appears in the L.sys file, the userid and
> the password. But, we are running this over IP so now we also add an ACL
> to our firewall which only lets machines with the right IP Address connect
> to the UUCP service. Still think you can get into my system?
I'm not going to try to get into your system. And I'm not going
to bet the security of my systems on what I may think that I can or
can't do to your system.
Anyway -- snoop on packets passing by to pick up the username
and password. Poison DNS to get accepted as the system and you are
still dead.
[ ... ]
> > O.K. But the *original* bang paths used machine names
> > exclusively.
>
> Ummm.... No. trotter.usma.edu!bill
> Maybe in the very early days,
Which is why I stressed "original" above.
> but later. Like everything else, it morphed
> to meet needs and adapt to a changing and growing network.
Yes.
[ ... ]
> >>>> There's a three part domain style name used in a bag path. yes, it worked
> >>>> just fine.
> >>>
> >>> But it required a system which understood FQDNs.
> >>
> >> Name one today that doesn't?
> >
> > My 3B1s if I don't install TCP/IP and ethernet cards. :-)
>
> Expecting your 3B1 to be taken seriously in today's networks is just
> plain silly. The fact is, it could play, but only with the help of
> others. But that is a shortcoming of the 3B1 and not the protocol.
> Especially when you take into consideration taht if you really wanted
> a 3B1 to be a part of a modern network the answer is to run modern
> software. What UUCP are you running? AT&T? Ever look at Honey-Danber?
Running none at present. But I ran HDB on the 3B1s, not the
AT&T one.
> That dates back to at least the 80's and was a great imporvement.
Yes, I agree.
> I
> don't know what it would take to port one of the current uucp's to a
> 3B1 but knowing how truly simple the actual software is, I would imagine
> it was doable. And then with sendmail or postfix as a frontend you get
> to play just like everybody else. Of course, the real problem is that
> the 3B1 only has a serial connection.
No -- *my* 3B1s had ethernet on the three systems which were
running full time.
> Oh wait, that simplifies all of
> it!! If you only have a serial connection you are probably going to have
> to just punt any email it generates to soemone else. And then he can
> handle the address resolution. Hmmm.... Problem solved.
:-)
> >
> >>> as it would not keep a track of the machines a spam passed through on
> >>> the way to you.
> >>
> >> There is no SPAM. People running MTA's will have a real (as in with real
> >> teeth) reason to not allow their users to SPAM as it would result in their
> >> loosing the ability to do email at all and might result in civil, financial
> >> penalties. And, as stated above, logs (which have been found to be legally
> >> binding in a court of law) will still record every machine an email passed
> >> thru. And, because email only passes between peers anyway, determining
> >> the paths is easy. Additionally, because the logs are maintained not
> >> as a part of the email but sparately ther eis no chance of forging.
> >> One could even go so far as to stop including path information in the
> >> headers of the eamil altogether. We have them now, but they are of
> >> dubious if any value because of the ease of forging them.
> >
> > O.K.
> >
> > [ ... ]
> >
> >>> While I'm having difficulty seeing how it would be implemented
> >>> with today's systems
> >>
> >> It is implemented. I am aware of no version of Unix that does not still
> >> have UUCP. It is a simple matter of adding (or rather, probably just
> >> uncommenting) an entry in sendmail or postfix (or whatever MTA you use)
Hmm ... I use qmail. I'm not sure whether it ever bothered to
support uucp. Since it ran a separate small program (smtpd) to accept
incoming smtp connections, I think that it did not. It would require
running something else to accept e-mail from a uucp spool.
> >> to have some or all of your email routed through UUCP as its transport
> >> protocol. The rest is merely finding peers and signing agreements with
> >> them.
> >
> > And -- trusting that uucp security is sufficient to the task. I
> > don't believe that it is at present.
>
> I would trust uucp a lot more than I would trust telnetd and everybody runs
> that!! And, if you are going to be that paranoid, you probably should never
> read Ken Thompson's "On trusting trust". :-)
No -- *not* everybody runs that -- for the same reason. I don't
trust it, or anything that allows passwords and usernames to come over
the net in the clear.
[ ... ]
> >>>>> O.K. Before DEC abandoned doing business entirely.
> >>>>
> >>>> Well, I meant DEC and theiur successors. The POSIX Kit was around for
> >>>> a while, but I believe thay have dropped it at this point.
> >>>
> >>> Is there someone keeping VMS going? Someone making the hardware
> >>> for it?
> >>
> >> Cetainly. It went from VAX to Alpha and now runs on Itanium. It belongs
> >> to HP.
> >
> > O.K. Is that still compatible at binary level with the earlier
> > systems?
>
> On a particular architecture VMS has always maintained forward compatability.
> That is programs from VAX VMS 5.5 could be run on VAX VMS 7.2. For obvious
> reasons the reverse is not true and has never been for anyone.
O.K.
[ ... ]
> >>> I have a business account. I have static IPs, and run both mail
> >>> and web servers on them.
> >>
> >> I guess I lost track of what the problem was then. You can pretty much
> >> do anything that's not illegal on a business connection.
> >
> > I just get sick of the calls, and stop them early with two
> > questions:
> >
> > 1) Can I get static IPs?
> >
> > 2) Can I get a class-C subnet?
> >
> > When they have to answer no to that, they leave until the next
> > call. It is quicker than trying to talk them down any other way.
>
> I just hang up when they identify themselves (or sooner if they refuse to
> identify themselves.) People think I am just rude, but my time costs money
> and I am not willing to give it to anyone for free.
I keep hoping that I can convince them that they are wasting
their time.
[ ... ]
> >>>>> I suspect so. Any chance of getting sufficient documentation
> >>>>> about the boards so you could write your own boot PROMs?
> >>>>
> >>>> Sure, I have all that. But it would be a lot easier if I had the MIKBUG
> >>>> PROM's as could then just use MIKBUG and download whatever code I was
> >>>> working on. Kinda like using ODT with either Kermit or VTServer.
> >>>
> >>> Hmm ... I never experience MIKBUG for the 68K systems, just for
> >>> the 6800. (Not even for the 6809.)
> >
> > No clue what else it added -- other than expanded motorla hex
> > dump formats for larger words and address spaces. :-)
> >
> > [ ... ]
> >
> >>> I can understand that. I'm glad to already be retired, but
> >>> there is too much to move to go to someplace like South Texas, where I
> >>> grew up.
> >>
> >> I would love that. I always liked San Antonio. But my wifes only taste of
> >> Texas was Ft. Hood and now she won't go near the place. :-(
> >
> > Even San Antonio would be a bit stronger military presence than
> > where I grew up -- about 90 miles south of San Antonio.
>
> Good thing it wasn't 100 miles south of San Antonio. :-)
Then it would have been 40 miles from Laredo instead of 50
miles. ;-)
The point was that it is far enough away so the influence of the
military bases would be minimal.
[ ... ]
> >> BSD, early versions of UCSD-Pascal. And then ther eis the one I plan on
> >> writing when I get the time. :-)
> >
> > O.K. is the BSD truly freely distributable? I though that the
> > PDP-11 BSD was still too full of AT&T code.
>
> Could be, but the holder of the Unix license has specifically released it
> for use. It is still being maintained and a new patch was just released
> a week or so ago.
When did they release it? That could make a lot of difference
in things. It could even have made the 3B1's source code available.
[ ... ]
> >>>>>> Yes. Came from the same vendor as the M68K.
> >>>>>
> >>>>> So they did not like the Vendor? Nothing to do with the
> >>>>> hardware?
> >>>>
> >>>> It was not a matter of like or dislike as much as a matter of control or
> >>>> not control.
> >>>
> >>> Oh -- they could control what Intel did, but not Motorola.
> >>>
> >>
> >> Well, once they bought 65% of Intel's stock they could. :-)
> >
> > Oh! And then they went to the PoowerPC -- from Motorola
> > originally, I believe.
>
> There has never been a PowerPC based PC.
I depends on what you call a "PC". The Mac ran on PPC until
recently, and it is as much a personal computer (e.g. made for the
consumer, not the serious user) as the Windows boxen.
> That was always another
> niche product, just like the M68K systems they made before the PC
> and continued to make and sell after they started doing PC's. It's
> all about target markets.
IBM is still developing and improving the PPC, for their own
serious servers and workstations.
> IBM knew how to do that, which is why,
> after all their problems, they are still there and still holding a
> major part of many markets.
Enjoy,
DoN.
Thad Floryan
None of them allow one to SEND email from a home consumer
account using port 25 per my own discoveries and those of many
clients.
Your posted log showed the "outside" connecting to your port 25
which is not the same thing.
The port 25 blocking by most ISPs is their attempt to thwart
spam into their MTAs; see the simple writeup at Sonic.net
whose URL I posted previously.
DoN. Nichols
> On Jan 22, 8:42 pm, "DoN. Nichols" <dnich...@d-and-d.com> wrote:
>> [...]
>> So -- how about comcast, charter, quest, swbell, and verizon?
>
> None of them allow one to SEND email from a home consumer
> account using port 25 per my own discoveries and those of many
> clients.
>
> Your posted log showed the "outside" connecting to your port 25
> which is not the same thing.
They should not be allowed to connect to port 25 from *any*
outgoing port. That is the problem which needs to be fixed. Only
systems which have static IPs and run true mail servers should be able
to connect to port 25 on other systems.
> The port 25 blocking by most ISPs is their attempt to thwart
> spam into their MTAs; see the simple writeup at Sonic.net
> whose URL I posted previously.
Yes -- they are protecting their *users* from externally
originating spam, but not protecting external sites from spam being sent
from their user's machines. *That* is the port 25 blocking which I want
to see -- which should be easily done at the routers.