Unless my leg is being pulled, I sent that for pure amusement.
Gcc has a very open mind on the subject, using both options
in the same sentence.
-----------------------------------------------------------
> Doug wrote:
> > A diagnostic from gcc chimes in:
> > 'mktemp' is deprecated: the use of `mktemp' is dangerous; use `mkstemp'
...
> https://www.gnu.org/prep/standards/standards.html#Quote-Characters
My impression was Doug was passing on a warning about the continued used
of mktemp(3) rather than the continued use of ASCII.
> From: Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org>
> Seeing as how this is diverging from TUHS, I'd encourage replies to
> the COFF copy that I'm CCing.
Can people _please_ pick either one list _or_ the other to reply to, so those
on both will stop getting two copies of every message? My mailbox is exploding!
Noel
> On Wed, Feb 06, 2019 at 10:16:24AM -0700, Warner Losh wrote:
> In many ways, it was a classic second system effect because they were
> trying to fix everything they thought was wrong with TCP/IP at the time
I'm not sure this part is accurate: the two efforts were contemporaneous; and
my impression was they were trying to design the next step in networking, based
on _their own_ analysis of what was needed.
> without really, truly knowing the differences between actual problems
> and mere annoyances and how to properly weight the severity of the issue
> in coming up with their solutions.
This is I think true, but then again, TCP/IP fell into some of those holes
too: fragmentation for one (although the issue there was unforseen problems in
doing it, not so much in it not being a real issue), all the 'unused' fields
in the IP and TCP headers for things that never got really got
used/implemented (Type of Service, Urgent, etc).
` Noel
> From: Kevin Bowling
> t just doesn't mesh with what I understand
Ah, sorry, I misunderstood your point.
Anyway, this is getting a little far afield for TUHS, so at some point it
would be better to move to the 'internet-history' list if you want to explore
it in depth. But a few more...
> Is it fair to say most of the non-gov systems were UNIX during the next
> handful of years?
I assume you mean 'systems running TCP/IP'? If so, I really don't know,
because for a while during that approximate period one saw many internets
which weren't connected to the Internet. (Which is why the capitalization is
important, the ill-educated morons at the AP, etc notwithstanding.) I have no
good overall sense of that community, just anecdotal (plural is not 'data').
For the ones which _were_ connected to the Internet, then prior to the advent
of the DNS, inspection of the host table file(s) would give a census. After that,
I'm not sure - I seem to recall someone did some work on a census of Internet
machines, but I forget who/were.
If you meant 'systems in general' or 'systems with networking of some sort', alas
I have even less of an idea! :-)
Noel
> From: Larry McVoy
> TCP/IP was the first wide spread networking stack that you could get
> from a pile of different vendors, Sun, Dec, SGI, IBM's AIX, every kernel
> supported it.
Well, not quite - X.25 was also available on just about everything. TCP/IP's
big advantage over X.25 was that it worked well with LAN's, whereas X.25 was
pretty specific to WAN's.
Although the wide range of TCP/IP implementations available, as well as the
multi-vendor support, and its not being tied to any one vendor, was a big
help. (Remember, I said the "_principle_ reason for TCP/IP's success"
[emphasis added] was the size of the community - other factors, such as these,
did play a role.)
The wide range of implementations was in part a result of DARPA's early
switch-over - every machine out there that was connected to the early Internet
(in the 80s) had to get a TCP/IP, and DARPA paid for a lot of them (e.g. the
BBN one for VAX Unix that Berkeley took on). The TOPS-20 one came from that
source, a whole bunch of others (many now extinct, but...). MIT did one for
MS-DOS as soon as the IBM PC came out (1981), and that spun off to a business
(FTP Software) that was quite successful for a while (Windows 95 was, IIRC,
the first uSloth product with TCP/IP built in). Etc, etc.
Noel
> From: Kevin Bowling
> Seems like a case of winners write the history books.
Hey, I'm just trying to pass on my best understanding as I saw it at the time,
and in retrospect. If you're not interested, I'm happy to stop.
> There were corporate and public access networks long before TCP was set
> in stone as a dominant protocol.
Sure, there were lots of alternatives (BITNET, HEPNET, SPAN, CSNET, along with
commercial systems like TYMNET and TELENET, along with a host of others whose
names now escape me). And that's just the US; Europe had an alphabet soup of its
own.
But _very_ early on (1 Jan 1983), DARPA made all their fundees (which included
all the top CS departments across the US) convert to TCP/IP. (NCP was turned
off on the ARPANET,and everyone was forced to switch over, or get off the
network.) A couple of other things went for TCP/IP too (e.g. NSF's
super-computer network). A Federal ad hoc inter-departmental committee called
the FRICC moved others (e.g. NASA and DoE) in the direction of TCP/IP,
too.
That's what created the large user community that eventually drove all the
others out of business. (Metcalfe's Law.)
Noel
> From: Kevin Bowling
> I think TCP was a success because of BSD/UNIX rather than its own
> merits.
Nope. The principle reason for TCP/IP's success was that it got there first,
and established a user community first. That advantage then fed back, to
increase the lead.
Communication protocols aren't like editors/OS's/yadda-yadda. E.g. I use
Epsilon - but the fact that few others do isn't a problem/issue for me. On the
other hand, if I designed, implemented and personally adopted the world's best
communication protocol... so what? There'd be nobody to talk to.
That's just _one_ of the ways that communication systems are fundamentally
different from other information systems.
Noel
On Mon, Feb 4, 2019 at 8:43 PM Warner Losh <imp(a)bsdimp.com> wrote:
>
>
> On Sun, Feb 3, 2019, 8:03 AM Noel Chiappa <jnc(a)mercury.lcs.mit.edu wrote:
>
>> > From: Warner Losh
>>
>> > a bunch of OSI/ISO network stack posters (thank goodness that didn't
>> > become standard, woof!)
>>
>> Why?
>>
>
> Posters like this :). OSI was massively over specified...
>
oops. Hit the list limit.
Posters like this:
https://people.freebsd.org/~imp/20190203_215836.jpg
which show just how over-specified it was. I also worked at The Wollongong
Group back in the early 90's and it was a total dog on the SysV 386
machines that we were trying to demo it on. A total and unbelievable PITA
to set it up, and crappy performance once we got it going. Almost bad
enough that we didn't show it at the trade show we were going to.... And
that was just the lower layers of the stack plus basic name service. x.400
email addresses were also somewhat overly verbose. In many ways, it was a
classic second system effect because they were trying to fix everything
they thought was wrong with TCP/IP at the time without really, truly
knowing the differences between actual problems and mere annoyances and how
to properly weight the severity of the issue in coming up with their
solutions.
So x.400 vs smtp mail addresses:
"G=Warner;S=Losh;O=WarnerLoshConsulting;PRMD=bsdimp;A=comcast;C=us" vis "
imp(a)bsdimp.com"
(assuming I got all the weird bits of the x.400 address right, it's been a
long time and google had no good examples on the first page I could just
steal...) The x.400 addresses were so unwieldy that a directory service was
added on top of them x.500, which was every bit as baroque IIRC.
TP4 might not have been that bad, but all the stuff above it was kinda
crazy...
Warner
> From: Grant Taylor
> I'm not quite sure what you mean by naming a node vs network interface.
Does one name (in the generic high-level sense of the term 'name'; e.g. an
'address' is a name for a unit of main memory) apply to the node (host) no
matter how many interfaces it has, or where it is/moves in the network? If so,
that name names the node. If not...
> But I do know for a fact that in IPv4, IP addresses belonged to the
> system.
No. Multi-homed hosts in IPv4 had multiple addresses. (There are all sorts
of kludges out there now, e.g. a single IP address shared by a pool of
servers, precisely because the set of entity classes in IPvN - hosts,
interfaces, etc - and namespaces for them were not rich enough for the
things that people actually wanted to do - e.g. have a pool of servers.)
Ignore what term(s) anyone uses, and apply the 'quack/walk' test - how is
it used, and what can it do?
> I don't understand what you mean by using "names" for "path selection".
Names (in the generic sense above) used by the path selection mechanism
(routing protocols do path selection).
> That's probably why I don't understand how routes are allocated by a
> naming authority.
They aren't. But the path selection system can't aggregate information (e.g.
routes) about multiple connected entities into a single item (to make the path
selection scale, in a large network like the Internet) if the names the path
selection system uses for them (i.e. addresses, NSAP's, whatever) are
allocated by several different naming authorities, and thus bear no
relationship to one another.
E.g. if my house's street address is 123 North Street, and the house next door's
address is 456 South Street, and 124 North Street is on the other side of town,
maps (i.e. the data used by a path selection algorithm to decide how to get from
A to B in the road network) aren't going to be very compact.
Noel
