Discussion:
An alternative history of computing
Add Reply
Simon Clubley
2021-07-14 17:40:36 UTC
Reply
Permalink
https://www.theregister.com/2021/07/14/alternative_history_computer_revolution/

DEC is mentioned (and keep reading to the end.)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Rich Alderson
2021-07-15 20:47:34 UTC
Reply
Permalink
Post by Simon Clubley
https://www.theregister.com/2021/07/14/alternative_history_computer_revolution/
DEC is mentioned (and keep reading to the end.)
Simon.
An amusing bit of fantasy, as are the comments.
--
Rich Alderson ***@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
k***@gmail.com
2021-07-16 22:22:19 UTC
Reply
Permalink
-----Original Message-----
via Info-vax
Sent: July-15-21 5:48 PM
Subject: Re: [Info-vax] An alternative history of computing
https://www.theregister.com/2021/07/14/alternative_history_computer_rev
olution/
Post by Simon Clubley
DEC is mentioned (and keep reading to the end.)
Simon.
An amusing bit of fantasy, as are the comments.
--
Rich Alderson
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--
Galen
Back in the peak days of DEC and shortly before black Tues when DEC stock dropped by approx. 50% in less than 2 weeks, there was a rumour internally at DEC that stated the BOD was considering buying some small networking company called ..... Cisco.

With stock drop, idea was also dropped, but under an alternative universe .....

😊


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
--
This email has been checked for viruses by AVG.
https://www.avg.com
Rich Alderson
2021-07-20 03:27:38 UTC
Reply
Permalink
<***@gmail.com> writes:

G> >-----Original Message-----
via Info-vax
Sent: July-15-21 5:48 PM
Subject: Re: [Info-vax] An alternative history of computing
https://www.theregister.com/2021/07/14/alternative_history_computer_rev
olution/
Post by Simon Clubley
DEC is mentioned (and keep reading to the end.)
Simon.
An amusing bit of fantasy, as are the comments.
--
Rich Alderson
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--
Galen
Back in the peak days of DEC and shortly before black Tues when DEC stock d=
ropped by approx. 50% in less than 2 weeks, there was a rumour internally a=
t DEC that stated the BOD was considering buying some small networking comp=
any called ..... Cisco.
I sincerely doubt that Len and Sandy would have considered an offer from
Digital, given the original business plan of Cisco Systems, which was to build
Len's TOAD (which stands for "Ten On A Desk"). Digital had already canceled the
36-bit line by then.

Cisco was not internally a networking company until 1990, when the BoD decided
that the original business plan was not where they wanted to put their money.
Len and Sandy departed quickly.
With stock drop, idea was also dropped, but under an alternative universe .=
=2E...
=F0=9F=98=8A
Regards,
Kerry Main
Kerry dot main at starkgaming dot com
--
Rich Alderson ***@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
k***@gmail.com
2021-07-21 21:59:58 UTC
Reply
Permalink
-----Original Message-----
via Info-vax
Sent: July-20-21 12:28 AM
Subject: Re: [Info-vax] An alternative history of computing
G> >-----Original Message-----
Post by Simon Clubley
Alderson via Info-vax
Sent: July-15-21 5:48 PM
Subject: Re: [Info-vax] An alternative history of computing
https://www.theregister.com/2021/07/14/alternative_history_computer_r
ev
olution/
Post by Simon Clubley
DEC is mentioned (and keep reading to the end.)
Simon.
An amusing bit of fantasy, as are the comments.
--
Rich Alderson
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--
Galen
Back in the peak days of DEC and shortly before black Tues when DEC
stock d= ropped by approx. 50% in less than 2 weeks, there was a
rumour internally a= t DEC that stated the BOD was considering buying
some small networking comp= any called ..... Cisco.
I sincerely doubt that Len and Sandy would have considered an offer from
Digital, given the original business plan of Cisco Systems, which was to build
Len's TOAD (which stands for "Ten On A Desk"). Digital had already
canceled
the 36-bit line by then.
Cisco was not internally a networking company until 1990, when the BoD
decided that the original business plan was not where they wanted to put
their money.
Len and Sandy departed quickly.
Post by Simon Clubley
With stock drop, idea was also dropped, but under an alternative
universe .= =2E...
=F0=9F=98=8A
Regards,
Kerry Main
Kerry dot main at starkgaming dot com
--
Rich Alderson
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
Minor correction to my original reply - " black Tues" crash should have
stated " black Mon" (crash of 1987).

Re: when did Cisco become a networking company?

See following link: (Wiki .. yes, I know ..)
<https://en.wikipedia.org/wiki/Cisco_Systems>

(kind of grey area between Stanford and Cisco, but early innovations were
focussed on networking, so even though not a company until 1990, not sure
what might have been informally happening behind the scenes at DEC in 1987)


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
--
This email has been checked for viruses by AVG.
https://www.avg.com
gah4
2021-07-16 23:12:26 UTC
Reply
Permalink
Post by Simon Clubley
https://www.theregister.com/2021/07/14/alternative_history_computer_revolution/
DEC is mentioned (and keep reading to the end.)
So, was there an Ethernet card for the Apple II?
Galen
2021-07-17 16:00:24 UTC
Reply
Permalink
Post by gah4
So, was there an Ethernet card for the Apple II?
I don’t know specifically about the Apple II family, but there was an AppleTalk/Ethernet adapter for the early Macs, with some application(s) supporting file transfer via, perhaps, FTP. We used them with mixed results at Lockheed in Sunnyvale, until the corporate small desktop standard was abruptly switched to IBM PC.

Did any Apple II model support AppleTalk?
gah4
2021-07-17 19:31:11 UTC
Reply
Permalink
Post by Galen
Post by gah4
So, was there an Ethernet card for the Apple II?
I don’t know specifically about the Apple II family, but there was an AppleTalk/Ethernet adapter for the early Macs, with some application(s) supporting file transfer via, perhaps, FTP. We used them with mixed results at Lockheed in Sunnyvale, until the corporate small desktop standard was abruptly switched to IBM PC.
You mean a Localtalk-Ethertalk gateway like the GatorBox? I might even still have one.
I was for a while working on school networking projects, and the schools had a lot
of Localtalk networked Macs.
Post by Galen
Did any Apple II model support AppleTalk?
I think there was Localtalk for some, maybe with an add-in card,
but the later models might have it built in. I believe the IIGS
has it built-in.

I think we did have a IIGS at one school, but I don't think I ever got
it on the network. The school had a GatorStar that I bought on eBay,
which by then were very cheap. (GatorStar is GatorBox plus a
12 port LocalTalk hub.) I think that would have allowed printer
access, and maybe file sharing.

We had Netscape 2.0 for a long time on the Ethernet LCII macs, as
the later ones were too big.
John Dallman
2021-07-18 10:27:00 UTC
Reply
Permalink
Post by gah4
Post by Galen
Did any Apple II model support AppleTalk?
I think there was Localtalk for some, maybe with an add-in card,
but the later models might have it built in. I believe the IIGS
has it built-in.
All the early Macs and the Apple IIGS had high-speed serial ports that
could be used for LocalTalk, at about 230kbps.

The IIGS was a much more advanced beast than the II, II+ or IIe, none of
which had any kind of built-in serial or network communications. There
were add-on serial ports for them, but they were limited by the low
processor performance: communications at 9600bps or faster required
disabling interrupts.

<https://en.wikipedia.org/wiki/Apple_II_serial_cards#Super_Serial_Card_%E2
%80%93_Apple_Computer>

A sensible LocalTalk interface card would have needed a processor and
buffer memory on the card, making it quite expensive. Ethernet cards
would be more expensive, and the ability of an Apple II to do anything
useful with Ethernet-speed communications is rather doubtful. Also, early
Ethernet cabling was thick, inflexible and expensive to install. The
story's author doesn't quite appreciate how limited the early 1980s
technology was in some respect; their thinking is more like the mid-1990s.


John
Andrew Commons
2021-07-22 07:44:22 UTC
Reply
Permalink
Post by gah4
Post by Simon Clubley
https://www.theregister.com/2021/07/14/alternative_history_computer_revolution/
DEC is mentioned (and keep reading to the end.)
So, was there an Ethernet card for the Apple II?
If you want a nice view of what was going on in those times look at "Accidental Empires" by
Robert X. Cringely (aka Mark Stephens).

In terms of Apple and Ethernet..In about 1990 my home office and development environment
consisted of an Apple IIsi, MicroVax2000, and a DecStation 2100. They all ran DECnet. In the
case of the Apple it was using an Apple Ethernet card with 3rd party DECnet software (the DECnet
specification was freely available). The IIsi had a laserprinter attached and made a nice little print
server for the MicroVAX and DecStation.
Simon Clubley
2021-07-22 17:52:28 UTC
Reply
Permalink
Post by Andrew Commons
In terms of Apple and Ethernet..In about 1990 my home office and development environment
consisted of an Apple IIsi, MicroVax2000, and a DecStation 2100. They all ran DECnet. In the
case of the Apple it was using an Apple Ethernet card with 3rd party DECnet software (the DECnet
specification was freely available). The IIsi had a laserprinter attached and made a nice little print
server for the MicroVAX and DecStation.
DECnet is not an open specification.

Parts of it are fully open (the lower-level NSP and related stuff) but
most of the higher-level application protocols are fully closed.

FAL is the only higher-level application protocol that is fully open.

The public CTERM specification is missing all the VMS extensions.

As for the others, show the known objects on your system and then
try and find public DECnet specifications for them. There isn't even
a public DECnet specification for the MAIL transport that I can find.

Now compare that to the TCP/IP situation. Everything there that is
part of a standard TCP/IP stack (including application protocols) is
fully open and documented.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
gah4
2021-07-23 12:00:11 UTC
Reply
Permalink
On Thursday, July 22, 2021 at 10:52:30 AM UTC-7, Simon Clubley wrote:

(snip)
Post by Simon Clubley
DECnet is not an open specification.
Parts of it are fully open (the lower-level NSP and related stuff) but
most of the higher-level application protocols are fully closed.
FAL is the only higher-level application protocol that is fully open.
The public CTERM specification is missing all the VMS extensions.
I don't know about openness, but I remember stories from the early
VAX days on how expensive it was. Expensive enough that people
would not network VAX systems because of the price.

Patents (if any) would have expired by now, though.
David Jones
2021-07-23 13:06:24 UTC
Reply
Permalink
Post by gah4
I don't know about openness, but I remember stories from the early
VAX days on how expensive it was. Expensive enough that people
would not network VAX systems because of the price.
Patents (if any) would have expired by now, though.
The first optical fibre backbone for the OSU campus network used
Proteon routers that supported DECnet as one of the protocols. Aside from
being slow, the option was very expensive. After a couple years, we dropped
DECnet from the contract and the backbone became TCP/IP only.
Arne Vajhøj
2021-07-23 15:36:05 UTC
Reply
Permalink
Post by gah4
I don't know about openness, but I remember stories from the early
VAX days on how expensive it was. Expensive enough that people
would not network VAX systems because of the price.
As I recall it then DECnet came with VMS.

But TCP/IP was an extra license and way back an expensive
license.

Arne
chris
2021-07-23 16:36:39 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by gah4
I don't know about openness, but I remember stories from the early
VAX days on how expensive it was. Expensive enough that people
would not network VAX systems because of the price.
As I recall it then DECnet came with VMS.
But TCP/IP was an extra license and way back an expensive
license.
Arne
Full decnet was an expensive layered product, from memory, though
a subset and run time libraries did come with vms.

Had a look at decnet at one stage, but already has tcp/ip on several
machines here, so ended up with the third party Wollongong TCP/IP,
from Oz, iirc. Got the job done, but the lack of industry standard,
shipped with the machine networking, was a serious impediment for
Vax and VMS.

The network was and still is the computer etc...
Robert A. Brooks
2021-07-23 17:02:29 UTC
Reply
Permalink
Post by chris
Full decnet was an expensive layered product, from memory, though
a subset and run time libraries did come with vms.
I'm not sure what you mean by "run time libraries"; there is
no run-time-only DECnet option for either Phase IV or Phase V.

DECnet Phase IV was pretty simple -- you had either a routing license
or an end node license. The X.25 stuff (VAX PSI) was separate, but that's not
DECnet per se. The NAS morass was simply a license bundling mechanism with
other stuff, but did not alter the DECnet functionality.

DECnet Phase V (known first as DECnet/OSI and now known as DECnet-Plus)
has more moving parts (the optional OSAK, FTAM, VT -- none of which require an
extra license), and its licensing also essentially follows the routing/end-node
paradigm. The X.25 stuff is again separately licensed.
--
-- Rob
chris
2021-07-23 18:15:45 UTC
Reply
Permalink
Post by Robert A. Brooks
Post by chris
Full decnet was an expensive layered product, from memory, though
a subset and run time libraries did come with vms.
I'm not sure what you mean by "run time libraries"; there is
no run-time-only DECnet option for either Phase IV or Phase V.
DECnet Phase IV was pretty simple -- you had either a routing license
or an end node license. The X.25 stuff (VAX PSI) was separate, but
that's not DECnet per se. The NAS morass was simply a license bundling
mechanism with
other stuff, but did not alter the DECnet functionality.
DECnet Phase V (known first as DECnet/OSI and now known as DECnet-Plus)
has more moving parts (the optional OSAK, FTAM, VT -- none of which
require an extra license), and its licensing also essentially follows
the routing/end-node paradigm. The X.25 stuff is again separately licensed.
So you are just confirming what I said then, that full decnet was an
expensive layered product ?. Thanks for the clarification though.

Most people expect networking to be part of the base os these days, as
machines are generally useless without it...
Arne Vajhøj
2021-07-23 18:27:06 UTC
Reply
Permalink
Post by chris
Post by Robert A. Brooks
Post by chris
Full decnet was an expensive layered product, from memory, though
a subset and run time libraries did come with vms.
I'm not sure what you mean by "run time libraries"; there is
no run-time-only DECnet option for either Phase IV or Phase V.
DECnet Phase IV was pretty simple -- you had either a routing license
or an end node license. The X.25 stuff (VAX PSI) was separate, but
that's not DECnet per se. The NAS morass was simply a license bundling
mechanism with
other stuff, but did not alter the DECnet functionality.
DECnet Phase V (known first as DECnet/OSI and now known as DECnet-Plus)
has more moving parts (the optional OSAK, FTAM, VT -- none of which
require an extra license), and its licensing also essentially follows
the routing/end-node paradigm. The X.25 stuff is again separately licensed.
So you are just confirming what I said then, that full decnet was an
expensive layered product ?. Thanks for the clarification though.
Most people expect networking to be part of the base os these days, as
machines are generally useless without it...
I agree that network is necessary.

But DECnet with end-node license instead of routing license
was still network.

Arne
chris
2021-07-23 18:36:55 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by chris
Post by Robert A. Brooks
Post by chris
Full decnet was an expensive layered product, from memory, though
a subset and run time libraries did come with vms.
I'm not sure what you mean by "run time libraries"; there is
no run-time-only DECnet option for either Phase IV or Phase V.
DECnet Phase IV was pretty simple -- you had either a routing license
or an end node license. The X.25 stuff (VAX PSI) was separate, but
that's not DECnet per se. The NAS morass was simply a license bundling
mechanism with
other stuff, but did not alter the DECnet functionality.
DECnet Phase V (known first as DECnet/OSI and now known as DECnet-Plus)
has more moving parts (the optional OSAK, FTAM, VT -- none of which
require an extra license), and its licensing also essentially follows
the routing/end-node paradigm. The X.25 stuff is again separately licensed.
So you are just confirming what I said then, that full decnet was an
expensive layered product ?. Thanks for the clarification though.
Most people expect networking to be part of the base os these days, as
machines are generally useless without it...
I agree that network is necessary.
But DECnet with end-node license instead of routing license
was still network.
Arne
Probably excellent when it was first released, back in the days
of isdn and X25, but who would choose it now, other than for niche
applications ?...
Arne Vajhøj
2021-07-23 18:41:46 UTC
Reply
Permalink
Post by chris
Post by Arne Vajhøj
Post by chris
Post by Robert A. Brooks
Post by chris
Full decnet was an expensive layered product, from memory, though
a subset and run time libraries did come with vms.
I'm not sure what you mean by "run time libraries"; there is
no run-time-only DECnet option for either Phase IV or Phase V.
DECnet Phase IV was pretty simple -- you had either a routing license
or an end node license. The X.25 stuff (VAX PSI) was separate, but
that's not DECnet per se. The NAS morass was simply a license bundling
mechanism with
other stuff, but did not alter the DECnet functionality.
DECnet Phase V (known first as DECnet/OSI and now known as DECnet-Plus)
has more moving parts (the optional OSAK, FTAM, VT -- none of which
require an extra license), and its licensing also essentially follows
the routing/end-node paradigm. The X.25 stuff is again separately licensed.
So you are just confirming what I said then, that full decnet was an
expensive layered product ?. Thanks for the clarification though.
Most people expect networking to be part of the base os these days, as
machines are generally useless without it...
I agree that network is necessary.
But DECnet with end-node license instead of routing license
was still network.
Probably excellent when it was first released, back in the days
of isdn and X25, but who would choose it now, other than for niche
applications ?...
From around 1995 or so TCP/IP changed from nice to have to must have.

Arne
chris
2021-07-23 18:56:36 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by chris
Post by Arne Vajhøj
Post by chris
Post by Robert A. Brooks
Post by chris
Full decnet was an expensive layered product, from memory, though
a subset and run time libraries did come with vms.
I'm not sure what you mean by "run time libraries"; there is
no run-time-only DECnet option for either Phase IV or Phase V.
DECnet Phase IV was pretty simple -- you had either a routing license
or an end node license. The X.25 stuff (VAX PSI) was separate, but
that's not DECnet per se. The NAS morass was simply a license bundling
mechanism with
other stuff, but did not alter the DECnet functionality.
DECnet Phase V (known first as DECnet/OSI and now known as
DECnet-Plus)
has more moving parts (the optional OSAK, FTAM, VT -- none of which
require an extra license), and its licensing also essentially follows
the routing/end-node paradigm. The X.25 stuff is again separately licensed.
So you are just confirming what I said then, that full decnet was an
expensive layered product ?. Thanks for the clarification though.
Most people expect networking to be part of the base os these days, as
machines are generally useless without it...
I agree that network is necessary.
But DECnet with end-node license instead of routing license
was still network.
Probably excellent when it was first released, back in the days
of isdn and X25, but who would choose it now, other than for niche
applications ?...
From around 1995 or so TCP/IP changed from nice to have to must have.
Arne
Agreed, must have been that time frame, perhaps vms 5.x something that I
last had anything to do with decnet. Even then though, is seemed so
wooden and didn't really talk to anything other than other dec machines.

Assume that now, a full tcp/ip stack does or will come as part of the OS
from VSI ?...
Simon Clubley
2021-07-23 18:59:29 UTC
Reply
Permalink
Post by chris
Post by Arne Vajhøj
But DECnet with end-node license instead of routing license
was still network.
Probably excellent when it was first released, back in the days
of isdn and X25, but who would choose it now, other than for niche
applications ?...
Unfortunately, there are still way too many people still using
DECnet Phase IV today. :-(

When VSI was deciding on the priority order for porting the various
layered and other products, DECnet was popular enough that VSI had
to move porting of DECnet Phase IV way up the priority list. :-(

I would love to know how these DECnet Phase IV users get through
a security audit in today's world.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Robert A. Brooks
2021-07-23 22:09:07 UTC
Reply
Permalink
Post by Simon Clubley
When VSI was deciding on the priority order for porting the various
layered and other products, DECnet was popular enough that VSI had
to move porting of DECnet Phase IV way up the priority list. :-(
DECnet Phase IV is tiny compared to DECnet Phase V, and was much
easier to port.

The port of Phase V is ongoing.
--
-- Rob
David Jones
2021-07-24 00:59:57 UTC
Reply
Permalink
Post by Robert A. Brooks
DECnet Phase IV is tiny compared to DECnet Phase V, and was much
easier to port.
The port of Phase V is ongoing.
--
-- Rob
Phase V is so bloated that initially DEC said you had to use a separate box
to be the router (and every network required a router).
Robert A. Brooks
2021-07-24 03:32:05 UTC
Reply
Permalink
Post by David Jones
Post by Robert A. Brooks
DECnet Phase IV is tiny compared to DECnet Phase V, and was much
easier to port.
The port of Phase V is ongoing.
--
-- Rob
Phase V is so bloated that initially DEC said you had to use a separate box
to be the router (and every network required a router).
Having attempted to run the notorious "Extensions to DECnet-VAX" on a memory-constrained
MicroVAX II, I am well aware of how compute-intensive Phase V is.

I am expressing neither admiration nor denigration of any phase of DECnet; I am
simply giving an update on the porting, and the rationale as to why IV was
done before V.
--
-- Rob
Arne Vajhøj
2021-07-24 01:18:09 UTC
Reply
Permalink
Post by Robert A. Brooks
Post by Simon Clubley
When VSI was deciding on the priority order for porting the various
layered and other products, DECnet was popular enough that VSI had
to move porting of DECnet Phase IV way up the priority list. :-(
DECnet Phase IV is tiny compared to DECnet Phase V, and was much
easier to port.
The port of Phase V is ongoing.
My guess is that there is a lot of code and DCL out there
that require DECnet but relative little that require DECnet
phase V.

When DECnet phase V finally arrived then the world had switched
to TCP/IP.

So DECnet phase IV will be enough for most DECnet users.

Arne
Arne Vajhøj
2021-07-24 01:27:16 UTC
Reply
Permalink
Post by Simon Clubley
I would love to know how these DECnet Phase IV users get through
a security audit in today's world.
If the auditors is one of those that follow a checklist and
require everything checked then the setup will fail the audit.

But if the auditor is one that does a risk assessment for
each problem and prioritize based on that, then there
will likely be way too many issues above DECnet phase IV
for it to get attention.

Example: if there is a system with both DECnet and telnet
allowed for login, then there will be two problems for
having protocols allowing login with plain text password
enabled. But if prioritized per risk, then telnet will
get the focus, because TCP/IP get through the network
while DECnet does not.

Of course if DECnet is the only problem then it will
catch serious flak. But most sites will have many
other issues not the least related to the applications
themselves.

Arne
Andrew Commons
2021-07-24 04:41:51 UTC
Reply
Permalink
Post by Simon Clubley
DECnet is not an open specification.
Parts of it are fully open (the lower-level NSP and related stuff) but
most of the higher-level application protocols are fully closed.
So, DECnet is/was an open specification.

Some of it can be found here:

ftp://bitsavers.informatik.uni-stuttgart.de/pdf/dec/decnet/

The fact that the layered applications were not open does not change the
validity of that statement.

Was it expensive? Yes, and so was the Operating System and the hardware.

Now add hardware/software maintenance and support on top of all that.

It was an expensive game to be in and maintenance bills came in two colours,
pale green and red.

Unix, on the other hand, was developed on DEC hardware up to BSD and System V.
Licenses were basically free if you were an academic institution, ditto for
TCP/IP. For maintenance and support you had mailing lists.

So cheap and cheerful won the academic space unless real quality and reliability was
needed - think SPAN and HEPnet.
Simon Clubley
2021-07-24 14:43:43 UTC
Reply
Permalink
Post by Andrew Commons
Post by Simon Clubley
DECnet is not an open specification.
Parts of it are fully open (the lower-level NSP and related stuff) but
most of the higher-level application protocols are fully closed.
So, DECnet is/was an open specification.
ftp://bitsavers.informatik.uni-stuttgart.de/pdf/dec/decnet/
The fact that the layered applications were not open does not change the
validity of that statement.
Unfortunately, a protocol which only opens its lower layers and only
1 or 2 of its upper layer protocols is not open in any way that could
accurately be described as open.

It would be like saying that TCP/IP is open if only everything at TCP
level and below was fully open along with FTP and a partial Telnet
specification while everything else in the TCP/IP stack was fully closed.

The point of an open protocol is that you can fully implement another
full version of it just by reading the specifications. You can do that
with TCP/IP but you most certainly cannot do that with the subset of
DECnet specifications that are available.

Not even the MAIL protocol is documented in public. That would be like
calling TCP/IP open while keeping the SMTP specification closed.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-07-25 00:26:49 UTC
Reply
Permalink
Post by Simon Clubley
Post by Andrew Commons
Post by Simon Clubley
DECnet is not an open specification.
Parts of it are fully open (the lower-level NSP and related stuff) but
most of the higher-level application protocols are fully closed.
So, DECnet is/was an open specification.
ftp://bitsavers.informatik.uni-stuttgart.de/pdf/dec/decnet/
The fact that the layered applications were not open does not change the
validity of that statement.
Unfortunately, a protocol which only opens its lower layers and only
1 or 2 of its upper layer protocols is not open in any way that could
accurately be described as open.
It would be like saying that TCP/IP is open if only everything at TCP
level and below was fully open along with FTP and a partial Telnet
specification while everything else in the TCP/IP stack was fully closed.
The point of an open protocol is that you can fully implement another
full version of it just by reading the specifications. You can do that
with TCP/IP but you most certainly cannot do that with the subset of
DECnet specifications that are available.
Not even the MAIL protocol is documented in public. That would be like
calling TCP/IP open while keeping the SMTP specification closed.
A protocol is open if it itself is documented.

Other protocols on top of it can be open or closed without
impacting that.

There are also closed protocols on top of TCP/IP - that
does not make TCP/IP closed.

Arne
Dave Froble
2021-07-25 02:27:17 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Simon Clubley
Post by Andrew Commons
Post by Simon Clubley
DECnet is not an open specification.
Parts of it are fully open (the lower-level NSP and related stuff) but
most of the higher-level application protocols are fully closed.
So, DECnet is/was an open specification.
ftp://bitsavers.informatik.uni-stuttgart.de/pdf/dec/decnet/
The fact that the layered applications were not open does not change the
validity of that statement.
Unfortunately, a protocol which only opens its lower layers and only
1 or 2 of its upper layer protocols is not open in any way that could
accurately be described as open.
It would be like saying that TCP/IP is open if only everything at TCP
level and below was fully open along with FTP and a partial Telnet
specification while everything else in the TCP/IP stack was fully closed.
The point of an open protocol is that you can fully implement another
full version of it just by reading the specifications. You can do that
with TCP/IP but you most certainly cannot do that with the subset of
DECnet specifications that are available.
Not even the MAIL protocol is documented in public. That would be like
calling TCP/IP open while keeping the SMTP specification closed.
A protocol is open if it itself is documented.
Other protocols on top of it can be open or closed without
impacting that.
There are also closed protocols on top of TCP/IP - that
does not make TCP/IP closed.
Arne
When this started, I just knew that some would come up with that "open"
word. Ya know, that word can be used in various contexts. "Open the
door." "The book is open." And such.

Regardless, the claim was "(the DECnet specification was freely
available)" The claim was never "open", and definitely not "open
software". I don't know how "freely" it was, but I do know there was
DECnet implementations on other than VMS.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Loading...