What you are actually logged into

A network engineer spends the day in interfaces: a web console, a proprietary command line, a management platform. Underneath almost all of it is the same thing. The load balancer has a filesystem with /var/log in it. The firewall runs cron jobs. The access point has a shell. When a vendor's documentation tells you to run tcpdump on the appliance, it is not an analogy - it is tcpdump, reading a BPF filter, writing a pcap file, exactly as the capture article describes.

That is worth knowing for a practical reason before a historical one: the moment you recognise the appliance as a host wearing a product, a large amount of troubleshooting instinct transfers. Disk full is disk full. A process that will not die is a process that will not die. Log rotation, file permissions, time synchronisation, DNS resolution, a full inode table - these fail on a firewall for the same reasons and with the same symptoms as anywhere else, and vendor documentation frequently describes the symptom without naming the cause.

1969, and the game

The origin is famously modest. Bell Labs pulled out of Multics, an ambitious time-sharing project it had been building with MIT and General Electric, in 1969. Several of the people who had worked on it - , , Rudd Canaday, Doug McIlroy - thought the project had taught them something worth keeping, and Thompson had a game called Space Travel he wanted to run. They wrote a small system for a cast-off PDP-7, starting with the filesystem. Brian Kernighan is credited with the name: Unics, a pun on Multics, later spelled Unix.

In 1971 they wanted a bigger machine, and the way they got the budget for a PDP-11 was by promising to write typesetting software for the Bell Labs patent department. The first production use of Unix was formatting patent applications.

The decision that made it portable

In 1973 Ritchie rewrote most of the kernel in a language he had designed largely for the purpose: C. At the time this was close to heresy. Operating systems were written in assembly because performance mattered and high-level languages were assumed to be too wasteful.

The payoff was that Unix stopped being tied to a machine. Porting it to new hardware meant porting a C compiler and recompiling, rather than rewriting everything, and by the middle of the decade the same source tree was running on equipment from several manufacturers. Every operating system a practitioner touches today descends from that decision - including the one inside the appliance in the rack.

The licensing accident

Here is the part that explains the shape of the industry, and it is not a technical decision at all.

In 1956 AT&T had settled an antitrust case by consent decree, agreeing to restrict itself to common communications - telephone and telegraph. Its lawyers read that as meaning no business other than phones. So when Bell Labs had an operating system, it could not sell it. A separate provision of the same decree required AT&T to license its patents at nominal fees, and Unix was licensed the same way: cheaply, to universities, with the source code.

And crucially, the licences were minimal. The software came as-is, with no royalties and no support and no bug fixes. That omission is the important one. Users who could not call a vendor fixed things themselves and sent the fixes to each other, and a culture of shared patches, shared tools and shared source formed around a product whose owner was legally barred from servicing it. The 1974 paper in the Communications of the ACM made the system famous; version 6, in 1975, was the first widely distributed outside Bell Labs.

An antitrust remedy aimed at a telephone monopoly produced, as a side effect, the distribution model that the software industry spent the next fifty years rediscovering.

Berkeley, and why every network program looks alike

The most consequential of the university licensees was the University of California at Berkeley, whose Berkeley Software Distribution became a parallel line of development. Berkeley's work is where a great deal of what a network practitioner uses every day originated - most importantly the interface a program uses to open a network connection, which was designed there and which is the reason that code written for one Unix compiles on another.

That is the second half of the protocol wars story, seen from the software side. won partly because it was free to implement and already running; it was already running in large part because it came in the Unix that universities already had.

Fragmentation, litigation, and the timing that mattered

Commercial Unix then split. Every large manufacturer shipped its own - Sun, IBM, HP, DEC, SGI - each incompatible enough to be annoying and similar enough to be frustrating, which is what was written to contain. Meanwhile ownership of the original code changed hands and was litigated over: Unix System Laboratories sued the Berkeley distribution's commercial arm in the early 1990s, and a decade later a further round of litigation attempted to assert claims against Linux.

The timing is the historically decisive part. The free Unix with the clearest legal position was tied up in court at exactly the moment a Finnish student announced, in 1991, a kernel he had written himself. Linux arrived without the encumbrance, and organisations that would have hesitated over a lawsuit did not have to. That is why the appliance in your rack is far more likely to be Linux than - though the BSD line is very much alive, and some network operating systems are built on it.

What this means when something breaks

The vendor interface is a filter, not the system. A management console shows what the vendor decided to expose. When the answer is not there, the answer usually still exists in a log file, a process table or a packet capture underneath.

Know where the support boundary is, and respect it. Most network vendors distinguish clearly between a supported command line and an underlying shell, and they do so for good reasons: unsupported changes are not preserved across upgrades, are not covered by support, and are not visible to the configuration management the platform relies on. Reading from the shell to diagnose is normal practice; writing to it to fix things is how estates become unsupportable. The correct use of this knowledge is to understand the diagnosis and then apply the fix through the supported path.

And the generic skills are the durable ones. Vendor certifications expire and product lines are discontinued - this catalogue is substantially a record of that. The ability to read a log, follow a process, filter a capture and reason about a filesystem does not, because it has been the same job since a group of people at Bell Labs wanted to run a game about flying to the planets.

Sources