Plug a sensor into a switch, wire up a building full of cameras, or rack a server, and you are using Ethernet. It is the most widely deployed wired networking standard on earth, the quiet backbone under offices, factories, and data centers. And it is named after a scientific idea that turned out to be completely wrong.

The name was not an accident or a marketing afterthought. It was a deliberate engineering choice, and the reasoning behind it explains why Ethernet outlived nearly every rival and still underpins industrial IoT half a century later.

A memo, a laser printer, and a dead theory

The date Ethernet enthusiasts celebrate is May 22, 1973. On that day, a young engineer named Robert Metcalfe, working at Xerox's legendary Palo Alto Research Center (PARC), circulated a memo describing how to connect the Alto - one of the first personal computers - to a new device PARC had built: the laser printer. The problem was getting many machines to share one wire without their messages colliding into noise.

Metcalfe needed a name for the shared medium that carried the signals. He reached back into nineteenth-century physics and borrowed the term luminiferous ether. For generations, physicists had assumed that light, being a wave, needed something to wave through - just as sound needs air. They called that invisible, all-pervading substance the ether, and they believed it filled the entire universe as a silent carrier of electromagnetic waves.

The trouble is that the ether does not exist. The famous Michelson-Morley experiment of 1887 failed to detect it, and Einstein's special relativity in 1905 made it unnecessary altogether. By the time Metcalfe wrote his memo, the luminiferous ether had been a discredited idea for decades.

He used it anyway, and on purpose.

Why a debunked idea made for brilliant engineering

Metcalfe later explained the choice plainly: "We called it Ethernet because the ether could be coax, twisted pair, radio, optical fibers, power line, whatever you wanted." The old physicists imagined the ether as a passive medium that simply carried waves without caring what those waves were. That was exactly the property he wanted his network to have.

By naming the system after an abstract, medium-agnostic carrier, Metcalfe was making an architectural promise. Ethernet would not be defined by a particular cable. The data and the rules for sharing the wire would stay the same whether the physical layer was thick coaxial cable, the now-familiar twisted-pair cabling, or fiber optics. The medium was just the ether - swap it out, and everything above it keeps working.

This is one of the most useful ideas in all of engineering: separate the thing you are trying to do from the specific hardware you happen to do it on. It is the same instinct behind a good driver, a clean API, or a well-designed embedded firmware layer that does not care which sensor is plugged in. Get the abstraction right and your design survives changes you cannot yet predict.

Why this still matters for IoT builders

Ethernet's medium independence is the reason it kept winning. Competing networking schemes tied themselves to particular cabling and faded; Ethernet absorbed every new physical layer and kept its name. The 10 megabit coax of the 1980s, the gigabit twisted pair in your wall today, and the fiber linking data centers are all still Ethernet at heart.

For anyone building connected hardware in the Philippines and beyond, there is a practical lesson here that goes well past trivia. When you design an IoT product, the connectivity layer you pick today - whether it is wired Ethernet, Wi-Fi, LoRa, or cellular - should sit behind a clean boundary in your code. The application logic that reads a sensor or controls a motor should not be welded to one radio or one transceiver chip. Build it the way Metcalfe named his network, and a hardware revision or a switch from one module to another does not force you to rewrite the whole system.

It is also a reminder that good naming reflects good thinking. The teams that named their projects carefully often did so because they understood the structure of the problem clearly. The luminiferous ether was wrong about the universe, but it was the perfect metaphor for a network meant to outlast its own wiring.

At Fluidwire we build IoT and embedded systems from silicon to cloud, and we design connectivity the same way: cleanly separated, so your product can grow without being trapped by the hardware it shipped with. If you are turning a thesis idea or a product concept into working, connected hardware, get in touch and let us help you build it to last.