My cubicle in the Adaptive offices was sandwiched between two coworkers: Krish Ramakrishnan and John Mayes. We didn’t know it then, but Krish would go on to start Internet Junction and Blue Jeans Network. John would someday be my partner at Network Translation, my first startup and where we created the PIX Firewall.
This would all be in the future, however. Back at Adaptive, Krish worked on defining the application that would run on my OS. John and I were going to tackle the OS itself.
He’d grown up in Bakersfield, California, where his dad owned a temporary services business. Our entrepreneurial upbringings left us with a lot in common. As a computer engineering graduate from Chico State College in Chico, California, John had developed a solid grasp of the foundations and a practical appreciation of the value of simplicity.
We have two other things in common. We’re both 5’ 8” (I maintain that I’m actually 6’ 5”. Well, I should be based on weight. I’m not overweight; I’m undertall!). More important, though, is our love for flying. When I started working for Adaptive, he had an airplane: a 1966 Mooney M20C Mark 21.
Before my move, Audrey MacLean mentioned that this John fellow could give me a flying tour around the area. She knew that Betsy, my wife, and I were living in a cabin in rural Georgia. She thought I might want to scope out a more secluded place to move than the valley... if I was comfortable in small planes. Ha! Truth be told, I was fed up with 70-minute commutes each way and we’d already decided to look in Palo Alto.
But there was no way I was going to turn down an opportunity to fly. That’s how I found myself riding in a pickup truck south on CA 101 to the Embarcadero Road exit, headed for the bay. The Palo Alto Airport was a twenty-five hundred feet asphalt strip almost at the water’s edge with 500 airplanes parked next to it. And that didn’t count what was in the hangars.
I climbed out of the truck and into the breeze. The cooler bay water gave the airport an almost permanent crosswind. It was refreshing, a tiny bit salty, cool, and left me with an anticipation I only feel when I’m about to do something flying-related.
I didn’t have my pilot’s license yet. My first three hours of flight training was interrupted by college, marriage, and then computers. John was entrepreneurial even in high school and earned enough to take lessons and buy the plane while only in college.
To this day, I still have some flying books he gave me. They have his old Chico address scrawled inside the front cover.
John climbed on the right wing and opened the only door to the low-wing plane. He slid across to the left and I climbed down behind him. The front panel was a bit of a hodgepodge with some avionics removed and their empty gaps covered with makeshift aluminum patches. All in all, it was a nicely equipped plane.
I left the door open for cooling, and John flipped on the master switch. The craft started to hum and I could hear the electric gyro in the turn coordinator spinning up. Lights came next. John turned a knob, pulling it out about three inches, and I heard fuel squirting into the void created by the piston the knob was connected to. After the sound stopped, he pushed it back in. I heard a quick squirting noise as the fuel made its way into the engine. He repeated the processes once again.
He cycled the throttle using yet another knob. Mixture rich. Carburetor heat off. Prop high RPM.
“Clear Prop,” he yelled through the small air vent on his side of the airplane. He turned the key in the mag switch three clicks to the right and then just a bit further. The prop swung as the whole plane shook with each compression of the 360 cubic inch engine. Suddenly everything was loud. John pulled the throttle back and motioned for me to put on my headset.
All my lessons were in a Cessna 152, a tiny two seater with only 135 horsepower. The Mooney had 180 and those last 45 were obviously much larger than the first 135.
We taxied the short distance from John’s parking spot to the runway. At the end of the taxiway, he stopped the Mooney at a slight angle. He pushed in the throttle, revving the engine up to 1,700 RPM, and switched the mags from both to right and then back to both. He was watching the RPM to see how much they dropped to make sure the right spark plug and magneto were in working order. He turned it from both to left, again checking the RPMs. All good.
He then pulled the knob labeled PROP and the engine seemed to bog down. This is how the pilot sets the RPM. When you take off, you want to go full out for the most acceleration. Once high enough, you set the prop to a lower RPM so that each swing of the blades takes a bigger bite out of the air. This is like shifting to a higher gear.
The “runup” over, we pulled onto runway 31 and opened the throttle.
The plane roared as it accelerated down the runway. At around 65 knots John pulled on the yoke and the nose raised. I didn’t need to look out the window to know we were in the air. I could feel it.
With a reasonable amount of air between us and the ground, he grabbed a vertical bar that connected the bottom of the panel to the floor. He used it to push the nose down a bit, making us light in the seats, then quickly rotated it rearward.
“Landing gear,” he commented over the headset.
We took a right over the water of the bay, turned south toward San Jose, and then headed west over the coastal mountains that lay between Silicon Valley and the Pacific Ocean. We got to know each other by chatting over the headset about one thing and another. Then he asked me a question about how we planned to get Unix on these MVME147 cards.
He talked about studying operating systems but explained that he only had an abstract understanding. The following is what I told him (with a few tweaks for the times--my conversation with John was, after all, almost three decades ago).
Today, most people use the Windows system. It’s really the most modern version of the Microsoft New Technology OS introduced a few years after that flight with John.
If you’re not using Windows, you’re most likely using Mac OS X which is based on the Berkeley BSD version of Unix. Or you might be one of the many readers of this blog who use one of the various forms of Linux.
All these OSs are collection of software that fall into a number of different categories. There are applications programs such as the browser, the word processor, and the mail client. All these are application programs, and some come with the OS and others are acquired later. Things like the notification center, the window manager, the printer manager, system configuration programs, are application programs but are provided by the system for the system.
But there are other application programs you never see. These are the daemons that run the printer, keep your files backed up, your email transferred, and many, many other important tasks. As I write this post, there are 351 total programs running on my Mac.
All of these programs share a bunch of code. Many of them are graphics programs, and they all need a large collection of subroutines to do the job of being a GUI. These programs link to a set of libraries provided by the system. These libraries are part of the application in that they run just as if they were compiled in the application.
Collectively, the end use and system applications plus the libraries are often what users think of as the OS. These make the Disney World we see, as we walk the streets of the Magic Kingdom. But, there’s an interesting space underneath Cinderella’s Castle just as there’s an interesting space behind the Utilidors of an OS. It’s called the kernel, and like the Disney cast member level, it’s what creates the magic of what appears above.
The part of the OS in the sunshine is called “user mode” and it’s where all the applications, libraries, and system code executes. User mode programs all think they are the only program running in memory and have the machine all to themselves. The kernel code running in system, “kernel mode,” actually creates the illusion for the programs running in user mode.
User mode sits on top of kernel mode, and at the base of the whole software stack is the actual processor. Until the mid to late 2000s almost all machines had a single processing unit. Made of two parts, the processor creates a kind of magic of its own. A calculating device, just a binary adding machine really, was controlled by a section of electronics that created an automaton.
The processor executes by reading numbers, called instructions, from main memory. Those instructions are called software. The processor fetches, decodes, and executes these instructions in a tight, never-ending loop. Today, that loop cycles over three billion times in a single second.
Those instructions are fairly primitive, even today. Mostly, they just add. There is a subtract instruction. It just negates the second number and adds. There is a multiply instruction, which often was just a trick for adding multiple times.
And so the loops cycle. This is a long way from running 351 programs that all think they’re the only machine in memory. That illusion is the magic of the kernel.
As I explain all this in 1990s speak, John flys up the coast to Half-Moon Bay. The mountains and landscape are truly beautiful. The narrow road between the coast and the Bay Area, CA 92, is just too narrow, confirming my decision not to move so far out.
“Do you want to fly?” he asked. He didn’t have to ask twice. The Mooney handled well. It was light on the controls and well balanced in the forces on the yoke. I made a few turns, and we headed back to KPAO while I continued to talk about the OS.
The kernel is in fact just a single program. When the computer starts up, the program counter, the register that contains the address in memory of the next instruction to fetch, is set to a predefined value.
Or, in the case of our 68030, it went to a memory address and loaded a value into the program counter. The CPU then started the automata act of fetching, decoding, executing, and pushing values through the mathy thing (ALU).
In the old days, we had to enter the very first code in something like a front panel with toggle switches or something. The very first operational computer, the Cambridge EDSAC, used part of a telephone switch to load a few instructions into memory on power up. On the CDC 6600 mainframe, there were 144 toggle switches hidden behind a panel, that allowed you to set the first twelve 12-bit words of the first peripheral processing unit. All these were just enough to load more software from something else.
These bits of code are called “bootstraps” because they are like pulling yourself up by your bootstraps. Unlike the pre-computer use of the phrase, we really can’t lift ourselves by our own shoelaces.
I turned toward the east, keeping the CDI needle centered for the Woodside VOR. We stayed below 4,000 feet, the floor of the San Francisco airspace, some of the most complex airspace in the world. Palo Alto airport lies just between the San Francisco and San Jose upside-down wedding cakes of controlled airpace.
In our system for Adaptive we will write a small read-only memory (ROM), that great invention of Intel from the 1970s that allows us to have some memory in the system when the processor comes out of reset. This EPROM will contain a very simple device driver for the disk, which will load a single 512-byte sector and branch to it.
The code in the first single disk sector will read in a longer, next stage bootstrap, called /boot. But even that boot strap is limited to only 10 sectors, or 5,120 bytes. That second stage bootstrap will then look for the file “unix” in the root directory, and load it into memory.
“/unix” is just a normal executable file. Nothing magic about the binary format except it will be linked to be loaded at location 0x80000000. Some assembly code at the beginning of “/unix,” the kernel, will set the MMU to map to that address, taking care not to mention absolute addresses since the MMU is not configured at that point.
“Palo Alto Tower, Mooney 9684M, over SLAC, inbound,” John announced.
The tower replied, “84M continue. Expect left base for 31.”
As we clear the 2,500-foot coastal ridge and wrap up our conversation, I realize how fortunate I was to have his help.
He tapped the airspeed indicators. “Getting a bit fast. You’re well into the yellow arc.”
I pulled the nose up a bit and the airspeed began to drop.
“Slippery airplane!” The Cessna 152 I flew was draggy, a good thing in a trainer.
“I’ve got it,” John says.
He called the tower again at base leg and we were cleared to land. He swung over the south bay and banked to the left, lining up with the 2,500 feet strip of asphalt tucked between the large tarmac and the south bay’s saltwater. As he made the turn he reached down and grabbed the handle of the Johnson bar, the other end of which is connected to the landing gear, swinging it up so that it clicks in place under the panel.
As he descended on final, crabbing a bit to the right to compensate for the on-shore crosswind, he slowly backed out the throttle, and gently, gradually raised the nose, slowing the Mooney, crossing the fence at only 30 knots over the stall speed of the low wing craft. He put down a small handle and pumps on a chrome bar beside it. It controls the hydraulic wing flaps. A little closer in, he pumped the handle twice more, putting the flaps all the way down.
Even before we arrived over the threshold, he pulled all the power out and raised the nose. Every so gently, the wheels kissed the ground, and he lowered the nose, letting the wheel in front touch.
As we leave the runway, John says over the headset, “I’m looking forward to working on this.”
Me too.
Inventor, coder, and entrepreneur, Brantley Coile invented Stateful packet inspection, network address translation, and Web load balancing used in the Cisco LocalDirector. He went on to create the Coraid line of storage appliances, a product he continues to improve today.