Golly, if you really wanted put a 'burn' in there, Rick, you could've mentioned this: http://books.google.com/books?id=qjsEAAAAMBAJ&lpg=PA34&dq=x-terminal&as_pt=MAGAZINES&pg=PA48#v=onepage&q=x-terminal&f=false
Although Metcalfe said it, I'm afraid the point gets lost in translation, almost always. What survived of Ethernet are really only two things: the name itself, and the format of the basic frame. That's it! In fact, there are more fancy IEEE variants of that basic frame now, still using the Ethernetr name.
Ethernet borrowed from other concepts, to keep itself viable. As speed increased, Ethernet dropped the shared bus medium and CSMA/CD protocol and adopted the rapid frame switching and full duplex links of ATM. (CSMA/CD is still there, but if used at all, it's only for a short point-to-point hop between one host and one switch port. Hardly what it was designed for!)
For the really fast interfaces, it adopted the optical transceivers of SONET.
And as Metcalfe said, it stayed strictly at layer 1 and 2, letting Internet Protocol (IP) take care of global routing between local networks. Where for example, ATM had its own global addressing and routing mechanisms, vying for the same roles as IP routing.
I think that the success of IP and packet switching, and the way Ethernet adopted techniques from other layer 1 and 2 network designs (the good ideas, leaving the not-so-good ideas behind), is what truly kept the Ethernet name alive.
It comes down to this: Ethernet, through all of its transformations, has always been "friendly to Internet Protocols." Much as SONET was friendly to ATM. So the true success story here is the way packet switching has pretty much come to dominate communications, taking over what used to be only circuit-switched networks or even virtual circuit networks. Ethernet and IP have been riding that packet switching wave together.
So via email, Bob Metcalfe tells me:
"THANKS! for your interview of me, which is great, except for one thing: I DO NOT SMOKE AND NEVER HAVE."
My mistake: The interview was done as a telecon and I thought I heard the sounds of Bob smoking and imagined the smoke, etc. My apologies!
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.