Blue Skies / 2

November 4, 2015 § Leave a comment

.

Late in his career, Freud, our god of psychic disturbance, had concerns as to whether or not we as a species were going to make it. Our instinct to assert ourselves, along with our tendency to self-destruct, he feared, was greater than any reactions we might form to divert the urge, than any concessions civilization might toss us in its desperate attempts to keep us all together.

Indians for centuries feared a god of death and destruction. But they worshipped him openly, calling him Shiva, the auspicious. Rationalization, maybe—flattering him thus put a positive spin on what would happen anyway, maybe gave a cover for their own disruptive desires. But they saw him as the force behind creation: through destruction we might be born again. And it was Shiva, ever alert in his eyes and below, who struck down Apasmara, the demon of insanity, and danced upon the prostrate body, blissfully waving his four arms in air.

Who’s right?

Our second winter in winterless California, ’91, while Marilyn was city planning with Montevista and trying to figure out what made Silicon Valley tick, while cruise missiles blissfully homed in on Baghdad and turned its night sky into floral splendor, finding their targets with a program that compared downloaded satellite maps with what cameras in their noses told them, I was madly writing drivers for a company that made network cards. A year later, while Allen was in the offing, I dove into Summit, a firm that made an operating system for networks themselves, a system that ran a server and managed the connection of PCs into local networks and local networks to each other, and, when the Internet burgeoned, networks to the world. We were developing the power to connect any point A with any point B: the world was within our digital grasp. Some good had to come out of getting it to talk to itself, in sending files instead of Tomahawks. Distinctions, however, have a way of breaking down.

But any ambition not only has to follow method and be tempered by means, but also face facts. In programming you not only have to know how to take all the small steps needed to reach a simple goal, but also find ways to direct traffic, resolve differences, and bridge gaps—create an interface—simply to let messages go through, and do so within what you and the machine can handle. On top of this put a face that a user will recognize and know how to use.

Then you have to factor in what happens when the logic of a program meets the logic of the world.

To write a program for the machine, you have to understand its resources and know how it runs its tasks, know its workarounds and find ways to work around them. And know not just the process, the execution of lines of code, the flow of data in and out, its storage and retrieval, but also how to manage interruptions when a user taps a key, another program, another machine calls. To be a programmer of the machine, you have to focus and keep track, stay beneath the ceiling of its logic, walk within the corridors of the process. And know how to manage your resources and handle disruptions and push distractions aside, but also push walls and find shortcuts with your energy, if you can. And you have to look ahead, to how well your program might face the future, to the time you have to face the fact that it has become obsolete, as well as look back, making sure your program is compatible with what has come before, and still keep an eye on the present, the machine’s current system, the programs with which it has to run. But you also have to look at what you have in front of you, now, and make time stop, now, freeze your program to debug it, stepping through it line by line and seeing what each returns, where it goes afoul, stop yourself to find what you may have missed running down your line of thought. What it most takes is a straight head and long patience, every now and then a flash of insight.

To write a program for the machine when its processor’s speed is doubling every few years and its memory and storage growing just as fast, when the buses that pipe data and instructions between memory and storage and processor are getting wider, faster, and its system is getting larger, faster, and the files it has to store and pass, graphics and databases and text, larger, and the other programs it runs more capable, larger, faster, and the devices, the other machines that connect to it more capable, faster, and the interruptions from all these are growing even faster—you have to come to terms with speed and size and conflict. To be a programmer for a larger, faster, more capable machine, you still have to manage and still push aside and still push yourself, but manage and push more, faster, push the size of what you know and manage to retrieve it, push faster to write more lines of code that tell the faster, larger machine what to process and store and retrieve, still have to focus and keep track, but focus and keep track of more paths, longer paths, of the multitude of possible crossings of piled on bits of simple logic, keep track and handle all the breaks, the interruptions, and still find shortcuts but also watch for detours and dead ends and be prepared for the unexpected when a dash down a straight corridor leads to an inexplicable crash. And still look forward, to the future, to obsolescence that approaches faster, and back to a past that recedes just as fast, and ever keep an eye on a present that seems to keep time with the processor’s accelerating beat, yet still stop time and debug, and stop and go more often, and stop and go faster, stop and keep debugging and revising and running and debugging and revising and running until you see your way through a stuttering now—or stop and throw everything out and start from scratch when your workarounds don’t work and keep starting over until they do. Along with a straight head, patience, and an occasional insight, needed are a few breaks.

To write a program for the larger, faster machine when its faster, larger chips and drives are getting cheaper, when anyone can make a clone and the market is suddenly flooded with cheap machines that everyone is buying and connecting, when the faster more capable devices are getting cheaper, when other software firms are turning out programs left and right that any and everyone would want to buy for their larger, faster, more capable cheap machines and devices, giving them the simple interface, point and click, and loading them up with features to point and click, then rushing them out to steal the march while Redmond is breathing down all our necks—you have to plan for chaos. More than ever you have to focus and keep track, more pick up speed and manage size and handle all the interruptions that come from all the other programs and devices, but also manage what you can’t keep track of, what comes from all the hands in the making, your team that has grown larger to make the even larger program, which, since larger, has become more incompatible with what comes from all the other hands that make the other programs with which you have to run, and more have to take shortcuts as well as make cuts and push aside what should be kept but can’t be figured out and settle for bottom lines. And then there is the world, less certain yet more sure of itself, its programs, its needs, its desires, its halls and crashes, and what can be cut and saved from those, what comes from all the things users can do, want to do with your program when they point and click, from all the ways they can screw up, and what comes from the guys who run your firm, the calls from management, their desires, their demands, their bottom lines, all the ways they can screw up, their proprietary maneuvers to make your program different, more special, and thus more difficult and incompatible, their deadlines to steal the march that come from nowhere and don’t give you time to design your program or test what might happen when users point and click all there is to point and click, the calls from marketing eager to give users something to point and click, anything, everything they might want to point and click so they won’t want to point and click your competition’s programs, that one more feature demanded at the last minute that you rush and throw in and that brings the ceiling crashing down. As ever do you look, but to a future that races towards you and slips past while time gets lost in department meetings, turf wars, pulled plugs, and projects that suddenly come out of the blue and leave it just as fast, the present becoming a spastic now that you don’t know how to stop but have to, so you make time, cram months into weeks pulling fifteen, sixteen, seventeen hour days five, six, seven days a week, fit yourself into the cycle of crunch time to get a project done followed by crash time to recoup so you can crunch once more, performing hack after hack, taking routes you don’t understand but somehow get you where you’re supposed to go all the while knowing your program will never work exactly right and all clarity and patience and insight and luck become subsumed into the prayer that you meet your deadline and your module works when the release is pushed out the door.

Not, of course, that we didn’t do it, write programs that worked, or worked well enough with the next decimal revision or two, or four or eight.

But the next years are a blur.

A network card is a piece of hardware that plugs into a PC and takes the cable that runs to a server. A network card driver is just the software that tells the PC the card is there and binds it to the PC’s system, allowing the PC to speak to a network and let data come and go, the user to use it. But there are layers of software to negotiate, and strategies that have to be deployed to grab the PC processor’s attention, to break into network traffic. Also matters of address and issues of compatibility, hard and soft. And a driver has to be both compact and efficient so it doesn’t tax the PC or create a bottleneck and leave the user wondering what is going on. It can take hundreds of lines of code.

Nothing I had done before prepared me for this work, but it didn’t take long to get up to speed. If you think in terms of the machine and software layers, instead of those of users and management, and find an appetite for details, a program falls into place. I met my deadlines and kept my code, my nose clean, even found a few spots in their drivers I could tweak. No one at the firm was impressed, but then again they weren’t unimpressed, so I supposed I was accepted and settled down in my cubicle, my box among many boxes in one of the many low-lying buildings off 101 whose form clung hard to function, coding away alongside the SF/Silicon Valley push. The job was not without its attractions. A driver can be a work of elegance, a gem with many polished facets, but after a while it just becomes so much bookkeeping, a taking into account all the standards that aren’t so standard. It wasn’t long before I started looking for work where the details added up to something more substantial.

A network operating system is a universe unto itself, self-contained and self-expanding, moved by the spirit of rapid flow and orderly division. And, when it connects users, it can be all-embracing. Not only does it have to manage itself and control and conserve the server’s hardware, but also work through the layers of communication and connect itself to all the PCs on a network and negotiate their different systems. It must know where the PCs are and keep track of them when they change, and show itself to them and what it holds, and open itself up to handle all their requests. It lines them up for a printer, routes their messages, takes and passes the files they send and ask for, and stores and organizes the files in hierarchies and keeps track of any changes here. If it connects to other servers, other networks, it has to organize and show and keep track of what they hold, and handle the requests that come from them. If databases and other network applications are added, it has to negotiate, show, and handle those. And it has to show and open itself up to the system administrator, who has to install and arrange the network and keep it up and running. And it has to be able protect itself from the PCs, decide what their users can do and keep them from doing what they should not, as well as safeguard what it holds by backing up files and deciding who can see what, which file can be changed by whom. And protect itself from breaks in the flow, and resolve conflicts and deal with errors and collisions. And it has to do all this with speed and transparency so users don’t have to wait and wonder about what is going on beneath the hood, yet remain stable so the network doesn’t overload and shut down and throw users in the void. Its code can run into the millions.

Summit, before it was called Summit, was a small network package with a quasi-technical, obscure name, which, like NetWare, was built from scratch, but which lagged well behind in market share. Then appeared everywhere, on billboards, in two page glossy spreads, only this, a thick black line that followed the contour of Mount Hamilton, breaking through a wisp of clouds—their new logo, soon followed by a beefed-up release of the system with its new name. Sales, stock soared, and while the technical press gave it mixed reviews, they treated it as a contender. It was a fluke they took me on because jobs with a firm that size and status were going to grad students from the best schools, to the guys with much more expertise and experience hopping around for top pay. I got the job because one Sunday, out running, I stopped in a park for a blow and was approached by K, a lead engineer at Summit, there taking laps.

Tall and pared to the bone, like a Giacometti statue, he spoke with a terseness that seemed to have been cut from something larger, which made one kind of sense, but perhaps not another. I don’t know where he got the K since none of his names had one. Kilobyte would have been too mundane, and while I doubt he took it from that Kafka character who found himself in a society whose system had bogged down and gone awry, I had the sense of someone who was all there and knew what he was about in a world that didn’t, then soon suspected the opposite was true. It wasn’t until I worked with him that I began to see how he thought, but still didn’t get very far.

Later I would doubt everything.

He told me he was impressed with the way I ran and I protested, because I don’t run that well at all. He persisted, though. He said he liked the way I kept my pace. What made me question him was what he might have concluded from that, because we started talking shop and I quickly saw he was out of my league, yet when I told him I was looking for a better job he said he’d put in a word.

What looked to be a flight from logic on his part became a leap of faith for me. I bluffed my way through the interview, showing an intimacy with drivers, shifting their questions to ones I could answer, or holding back when I could with a straight knowing face. Sometimes silence, played right, can go a long way. Or maybe K had more pull than I realized.

But not bluff, or bluff entirely. You’ll never know what you can do until you push yourself and try, and won’t get far if you don’t push yourself hard. Around here, you won’t get anywhere. Then I woke up one morning and found myself mired in a system that overwhelmed me, wondering how long I would survive.

I was put on the team revising the redirector, the other piece of network software installed in a PC that loads after the driver and presents the network, and decides whether requests from a user, from another application, can be handled by the computer or should go out into the network and be taken by the server. The issues of interface and complexity I saw in drivers were compounded, the relationship between the server’s system and the PC’s taken down a level, closer and more problematic. I now spent hours in a maddening rush, trimming, jockeying the code that handled all the exchanges and maneuvers to get the program to fit within the PC’s memory, and tracking down bugs that cropped up where I thought the program had been tamed, and trying to figure out why a PC crawled when connected to our system or what ran into its system from ours and made it hang and turn its video screen black.

Nothing in the code did exactly what I thought it was supposed to do. Everything I thought I knew was called into doubt. The parts I was assigned to rework that looked simple, a night’s dash at the keyboard, could take a week, most of that time spent in fruitless debugging, a rolling of rocks up hills only to have them fall back down once close to the top, each step towards order only inching me closer to my unraveling. Shipping dates that first seemed reasonable appeared out of reach, my dismissal imminent. In a world ruled by logic and peopled by the best minds, I could only assume that the difficulty came from my own failings. Only after I got my bearings did I see that much of the confusion was not mine.

Summit, I came to learn, was something of a bluff itself. The firm got venture bucks from Sand Hill to fund its expansion with a business plan that was largely smoke and mirrors. They undercut Novell in price, yet their sales projections were surreal. And while they pointed to their graphic interface, their ability to scale to larger networks, and a global directory service to manage and keep track of all the files spread across the servers, all this stuff was already in the works at Novell. When NetWare 4.1 appeared, a half year later, essentially the products were the same and the only real differences were bells and whistles.

A good part of the money went to us, the programmers; another chunk to build our campus, here in Montevista, which had the sparse, modern architecture you see in sci-fi movies where it appears the future has brought order and harmony but something is not quite right. A ton went to marketing, whose slick campaign caught on and kept attention. When they finally descended the slope of the Summit logo, they showed ads of us, the users, working in the same places we had always known, doing the same things we had done before, but now in ways which, while not quite mystical, were not quite of this world, the Summit logo now appearing in the background on the screen of our PCs. When they finally got around to actually referring to the product, they trumped up the minor differences and rephrased standard features to make them sound phenomenal and new, while their performance figures came from tests that simulated conditions less than real life. As much went to sales, an aggressive force who made their pitch to large firms shifting from mainframes to PCs and hit hard those not yet connected—small, medium-sized businesses, and local government and private institutions, especially the schools, who had more than open ears—maybe talking them into a system larger than they needed.

Meanwhile Summit, the company, was bleeding cash, which accounting found creative ways to disguise to keep Sand Hill and Wall Street content. Where the money didn’t go was testing for us, or for users tech support, whose small staff couldn’t handle all the calls. Summit, the system, was buggy and crash prone, a resource hog that couldn’t run well on anything less than a 486 Intel chip, then the fastest, and even there was sluggish. And despite their claims of GUI ease, Summit was a bear to set up and maintain, a puzzle to users once installed.

Nothing new here, not that Summit was alone in misdirection. Besides, sales is sales, advertising is advertising. We all are suckers because we like getting sucked in, every now and then. It lifts us off the ground and takes us outside ourselves, makes us think of other things. And we were thinking of other things, and believed getting connected would help us see those things more clearly. And we were getting connected. Prices of hardware and connections were falling fast and we were hooking up just as quickly—Netware at the time was adding a million of us a month—in addition to the banks and insurance companies and airlines and major corporations, now retail outlets and brokerage firms and publishers and ad agencies and PR departments and lawyers for the rest of us, the service industry and social services and charities, and hospitals and libraries and license bureaus and the police, getting connected and printing out and passing on memos and reports and spreadsheets and graphs and graphics, inventories and identities and vital statistics and layouts and emendations, balance sheets and projections and spins and takes and spreads and symptoms, and diagnoses and precedents for the rest of us, updating lists of customers and suppliers and donors and suspects and absent fathers, linking not just admissions and records, and science and computer science, but now English and philosophy departments, passing on whatever it was they passed. Summit only had to get its share and build from there.

And bluff is part of the game. Or not bluff, because everything was smoke and mirrors then. Reality wasn’t what we needed to discover then adjust ourselves to but what we were in the process of redefining, or recreating. For us, the users, it was impossible to predict where networking would take us; for us, the programmers, it was impossible to anticipate all the problems we would encounter with a system so large and complex. We all first had to get in and get going, then figure out the rest as it came. As for Summit, they had to get in quick, build a user base, and worry about cash and details in the program later. Nothing here comes to patient. Netware showed no signs of letting up and Microsoft was giving away their small network manager dirt cheap while hammering away at Windows NT, the system to serve all our computing needs, and then some.

Summit placed its faith in us, who made the system. They loaded up with everyone who caught someone’s eye and turned us loose—hackers, self-taught whizzes; the roaming pros, industry adepts; top grads and some of their professors, masters of theory and the arcane—swivel chair riders turned mavericks and gunslingers and warriors and tribal chiefs, the cowboys and Indians tearing across our western plains. Also long shots, like me, as well as K, whatever category he fit in, if he did, although I scarcely saw him the first year, then he dropped out of sight. They believed we could do anything, the more of us the better. Some of us were beginning to believe it ourselves.

And still not entirely bluff. If you don’t stretch belief you won’t see past what you already know and remain stuck there. Reach, solve problems, and their magnitude diminishes, thresholds become small steps.

And we had reached and moved on. We had advanced in not that many years from the Gates box that analyzed traffic on corners of Seattle to writing systems that could handle the city’s business, had moved so far so fast, several orders of size and complexity, that we could only look ahead.

And I had reached and moved on. I figured out what I needed to do and within a year was inside the system itself, working on its memory allocation code, then tuning its scheduler to wake up faster and push larger files through the larger, faster lines. And I began to look ahead. I could think in larger terms, of the possibilities of a whole, its possibilities.

Maybe we looked so far ahead that we lost sight of what we were doing, although I’m not sure all of us were certain what that was.

Creating a new system, however, would have required years Summit couldn’t spare, so we had to build on the previous system and work with its assumptions of only a few seasons back, these based on hardware capabilities and processes of the time, too entrenched to change but already out of date. Add to this the push from management to get Summit, the system, up and running as soon as possible, who had no idea what this would take.

While I suppose it worked well enough for what it was designed to do, the old version, manage small networks, it didn’t itself have a clear sense of itself within itself, of what held its parts together and how they passed data back and forth. Or without, of how users broached the system, what they could do within it, or with each other. We had to build on top of its uncertainty and scale up from there for the larger drives, the larger, faster CPUs, taking it on its own shaky terms but adding restrictions and special cases to what should have been reworked and left alone. Or we threw out the obsolete where we could and tacked on our own parts, redefining for ourselves what we were doing without having a central scheme to guide us as we tried to build the new system to manage the larger networks of the world.

But we also needed to look at ourselves, at our assumptions, at the spirit that moved us. The problems Summit posed were huge, and thus required answers, we believed, of a size to match, that could only be found by pushing the limits of our abilities and our ideas. We wanted to prove ourselves, and strove to outdo ourselves and each other. We also didn’t talk well—and didn’t see the irony in that, considering what we were making—but clashed and ran together in ways that could not be sorted out. Meetings lasted forever, going everywhere and nowhere, where whiteboards became fields of battles over game plans that resulted in busted plays. Or we kept to ourselves, either not deigning to spell out what anyone who knew his stuff should understand, or not questioning so as not appear as one who didn’t. Commenting in our code was sparse and cryptic, or nonexistent; in our units we talked of other things.

I don’t think it was just ego, though, but also the nature of our field, necessarily removed because of its large technical demands, which, in their difficulty, their loftiness, called us to reach their heights. This and something else we felt but did not know how to express, that we and what we were doing belonged to some higher realm that couldn’t be grounded in the obvious but would reveal itself in ways no one could imagine, our place there confirmed by the world who had begun to watch us and wait eagerly to see what we would turn out next. Or maybe it was only ego. The campus was charged with wonder and the tension from what was left unsaid.

As for us, for our system, mystery and angst. Our solutions tended to abstraction and complexity, resulting in components that were theoretically marvelous but opaque and fragile. Where theory didn’t quite reach came the kludges. Code should explain itself, in its writing make apparent what it does and how it does it. Not only did one team have to struggle to understand the parts another had made, we had trouble putting in words how our own functioned, so rarefied was our thought. A program should be composed of modules that fit cleanly and work together without interfering with one another. The interfaces between ours were thick and involved, and they intruded on one another in hidden ways. A software firm has libraries of code for reuse. I got so frustrated trying to figure out ours and getting it to work that I wrote my own, as did many others. At least I knew what I was doing, though I thought I was wasting time and was uneasy about how well what I wrote would work later when other code got piled on top. When we ran a build it was hard to tell what went wrong where, or even when we hit the mark. Our system was a universe of wormholes and black stars.

For us, and for our users. Summit rewrote the language of networking, inventing its own terms for setting up a network and for identifying users and their place in its domain and describing what they could do there when they entered, terms that tried to express both the ease of being there and the specialness of being there with Summit and its wizards, but did neither and left them in the dark. Where we couldn’t think of a term that might comfort and promote, we resorted to technical terms that didn’t suggest anything and technically referred to nothing outside of the techniques we had devised for ourselves. To explain ourselves, our manuals, which labored the obvious, skirted the difficult, and left holes for questions that we hadn’t anticipated or thought important.

Along with our language, our pictures, our GUI—our windows on our world—which, while they might make users feel at home, can only go so far in a network system, yet were trendy, and thus thought essential. Also because of Windows, and they gave Summit a chance to get its logo on every dialog box and spread the Summit mystique. The coding for simple boxes, buttons, and pull-down menus, however, is complex and takes volumes of special code; our solutions here were messy. On top of these, lapses of simple reason. Our picture of a printer did not look like any printer our users had ever seen, our error messages didn’t make sense. Users had trouble just finding basic commands, weren’t even sure how they were supposed to log on. And giving complicated tasks a simple appearance only makes them harder because you can’t see what goes on behind the pictures. Administrators who had to get inside the system screamed for more control so they could make Summit do what it had to do for them. I don’t think it’s so much that we thought our users were idiots, rather that we were uncertain of their existence. The icon of a person, the image we used to represent our user, was rather cute.

What most mattered was what lay beneath the surface, and above. Summit didn’t stand up well to what we had opened the flood gates, the push of the real world. Our hacks on the kernel, the system’s core, to boost performance made Summit prone to panics and corruption. What was not well defined and separated was left exposed. Summit could not protect itself from itself when processes ran afoul, or from users who strayed, or protect users from each other, a problem that didn’t hit home until we added a hookup to the Internet and diseases spread, break-ins became epidemic. And the code was so large and involved that some of us doubted we could ever get it to perform as it should or be able to plug all the leaks, that it wouldn’t stand up to what the future was going to throw.

Still, we did get converts, and many of our followers stayed with us and learned once more how to follow. And we flushed out the worst bugs and got Summit, the system, running well enough. Our pride and incomes, after all, depended that we did. Ultimately we were engineers, makers whose identities were based on making things that worked. Also we were good, some of us the best, and reasonable at heart, or wanted to be, though many of our sins were covered by the larger memory and faster chips. But really Summit, the system, didn’t perform well except with a ton of RAM on a Pentium chip when it came out, which, in terms of price, put it out of reach for many. So Summit, the company, had to bide its time until prices for both came down. In the meantime, they were stuck with a program that didn’t distinguish itself in any significant way from the others for the better, a user base that wasn’t growing fast enough in a PC market that was saturated, or so the industry analysts feared in ’94. All the while they were still bleeding cash.

And while my paycheck and status kept going up, I never settled in. The time I spent climbing Summit, pushing Summit time and memory, had warped my sense of both. Months rushed by, standing still. The more I learned, the less sure I felt about what I did, what I knew, or what I should remember. The only thing I can point to is that I wasn’t left standing when the music stopped, the system crashed, and the problem could be traced to me.

I wasn’t going anywhere, rather felt like I was back where I started, in Detroit patching up a botchy system, with only this difference, that one kind of shortsightedness had been replaced with another, that the compromises once made from inertia, meanness, and ineptitude now came from excess, property, and show. I got an ulcer at 27 and couldn’t sleep, when I did, had dreams of people I didn’t quite recognize doing things in a hazy place, who weren’t quite of this world or any other. When I woke up, I went to work and saw the same.

.

.

New pitcher for our team—the coaches don’t want to run their kids too long this early in the season.

Our head coach’s son—he must be, now that I see him on the mound, because he has the same reserve, the same gently sloping forehead, emerging, a slight but forceful plow, the same open gaze that shows not hope though maybe faith, or faith emerging, but largely sheer confidence, stirred, perhaps, by his counterpart’s performance and sharpened by the moment, the task at hand.

Something is in the air that wasn’t there before.

And now, looking forward, he stares down the chute.

And now he sets and winds.

.

.

Summit, I discovered, had hedged its bet. At a time when the major outfits were blitzing the nation and working behind the scenes to become the PC operating system of choice, Summit decided they had to do better what they were doing, make a network system that worked well and that most of us could use well enough. Really, given the others’ money and clout, it was the only option they had. To do this, they remade their system once more, this time putting it on top of Unix, transforming Summit, the system, into Summix, only a year after Summit hit the shelves and still hung in the mists.

It was a time, not long ago at all, when the industry paid a lot of us to sit in back rooms and think, believing that anything we came up with that was strange and new and pushed the machine to its limits could be turned into cash, a time of oddities and our most creative work. Unix was K’s idea, though there was nothing extreme or new about it. First appearing some twenty years before, back in the days of the big boxes, when a system had to be written for a specific machine and programs had to run straight through in batches, Unix was designed by a pair of transcendent minds at Bell Labs, Ritchie and Thompson, who wanted a system that was machine independent and would allow programmers to halt the ponderous beast and interact, whose ruling passion was to keep it simple. Antitrust wouldn’t let AT&T sell Unix, so they gave it away, and hackers and universities added to and fine tuned it ever since. But other than Sun’s version and a few others for work stations and high end machines, it hadn’t had much commercial success. Businesses, lay users found its interface weird and saw it as the system of geeks.

K’s motives were technical, however, not economic. Or maybe moral. Or esthetic. Or all three or none of those but something else. I never did understand what moved him, there were things he did not explain. At any rate, his argument was that Unix was robust, a term that appealed to management egos and soothed their unvoiced fears about Summit, the system and the firm, their uneasiness about where both, they stood. PCs were large and fast enough to handle Unix now and they could add any user interface they wanted. But they had to find the code. When AT&T split they took control of their version, then later sold it to an outfit that wanted to make Unix all its own. So K talked Summit into buying out Rosebud, a company that years before tried to make a go of Unix and hadn’t gotten anywhere. Then he went off site with eleven others to create Summix in secret, away from the fray—the reason I hadn’t seen him.

I also don’t know why he asked me to join the team as I didn’t think I had done much more than keep my head above the waters. It was something else you didn’t ask him. I was ready for any kind of break, however, and once again jumped at an offer without knowing what I was getting into, then spent the next three years with K and his disciples, coding away in one of the faceless buildings on Bubb Road, quiet except when the middle school around the corner let out and kids trudged by with loaded backpacks, a caravan of mothers in minivans and SUVs passed.

Basically a basic box, with a small, obscure sign out front that conjured nothing, 16954 Bubb was an apt place to work on Unix, itself a system that separates itself from noise so it can focus on its work. At its heart, the kernel, which sits on top of the hardware, handles the basic functions of storage and memory, and schedules and runs tasks on the CPU, the processing in and out of requests from above. Above, applications and users, who make the requests to tell the hardware to do whatever it is they want done. Between the kernel and applications and users, however, the shell, which translates requests into calls for the kernel, thus separating what comes from above from what goes on down below.

Only a small part of the kernel has to be written to meet the specifics of the hardware. The rest of the kernel and the shell are written for themselves, and applications are written for the shell, which is what makes Unix independent and portable. Also its memory management won’t let one process creep into another’s memory space, and users are kept apart by a system of privileges. Because of this separation and translation, applications and users don’t have to worry about the hardware’s innards, users are protected from each other, and the kernel is protected from errant runs that can screw a system up. And GUI pictures can be placed on top of everything so users don’t have to type commands into the shell but point and click without having to know or worry about anything except what they are trying to do.

Along with the kernel and shell, hundreds of utilities and commands, accessed through the shell, that do one thing and that can be easily combined to do another, which are used to shape the system however its needs to be shaped. Also tools to write, compile, and debug whatever else needs to be written, and large libraries of functions to support programming, code that can be reused. Add to this vast archives of the work of Unix programmers across the spectrum. As much an actual system, it is a system of possibilities, waiting to be put together.

At least I knew the language, C, designed by Ritchie along with Unix to make the system intelligible, but I didn’t know much else and was anxious about what I could do, how the others would take me. Unlike Summit, the system and the firm, in both Unix and our closed box on Bubb mistakes showed up fast. And these guys were sharp. They talked with an easy precision that showed how much they had in place, and their pauses implied even more. But I was never singled out, comparisons were not made. They simply put me to work and let my work speak for me. When it didn’t, it was left to me to come to the obvious conclusion to hit the keys and start again.

I have since come to believe that the only people who really know what they are doing don’t show it, or feel they have to mask it in a backward guise of modesty or show others up. Perhaps because people who know what they are about have nothing to prove, or are smart enough to realize that proving oneself doesn’t prove anything. Or maybe because once away from Summit they were removed from the need for pretense and were allowed to do what they wanted, and what they wanted to do was do what they knew how to do and do it right. Or maybe some of us had given show a good run there and got to see it for what it was. And saw that pretense, like humility, was just a waste of time.

Or maybe humility after all, or not humility but the sober recognition that comes to anyone who really knows his stuff and has been around long enough to learn that there’s only so much one can grasp, so much one can do. With us, it was the realization that our programs now were becoming so large and complex, their relationships with users and other software just as involved, that however we made them we’d never be able to predict all the circumstances they’d have to meet, all the interactions with which they’d have to contend. There were no silver bullets. This difficulty was magnified by what our systems now had to face, what we had created and had taken off without us, the worlds of networks, ever growing larger. We were moving from unpredictability to the unfathomable and approaching chaos.

And/or maybe they took their cues from Unix. Unix is as much a philosophy as a specific implementation, a theory of making a whole from separate, solid parts. With philosophy comes practice, guidelines that determine how a system is put together and steer it from conflict and confusion. Learning these helped me understand Unix, write for it, and avoid the same. Make a program that does one thing, and one thing well. Build it with simple modules, and design the methods, the conventions that determine what passes between them—their interfaces—clean. Have a clear sense of what a program is supposed to do as well as how it is supposed to do it, respecting the integrity of its mechanics and not letting uses, what comes from above, intrude and compromise the works. Following these rules not only helps you see what you are doing, but also keeps problems in your programs local instead of spreading out into the system where they can’t be tracked down.

Not just define purpose and mechanics, but show them. What most helped me learn is the Unix tenet that a system should reveal itself and talk, that process be should be made visible, the implicit made understood. Thinking should approach the self-evident, the model that describes how a program is supposed to act be devised in such a way, direct and simple, that is readily apparent. What you can’t explain to yourself now won’t make sense to you or anyone else later who has to go back in to modify or fix what you have done. Facilities should be built in to display a program’s internal states so you can trace the process. Wherever possible pass text, not opaque machine code, and have programs talk to each other in words that people can read and manage. Name parts, variables and functions, with terms that refer to something that can be conceived now and will mean something later. Comment on your code as if writing for someone other than yourself; document for the world.

What goes for Unix went for the group, they talked and assumed that I would join them. Knowledge was shared and gathered in upward building, not hoarded, or chiseled out by attrition, our tearing each other apart until the last man, the last idea stood. When we had questions, we asked them. When we understood something, we said it. When we didn’t, we said that as well. And we reveled in announcing our mistakes and failures because at least we were able to identify with certainty something that wasn’t right, deal with it and put it behind us.

Talk not just because we needed to pass on what we did know, but as much because we had to have a way to approach all that we did not. Because our goal was not to design some Platonic system reached through intense, internal contemplation of absolutes that would send documents between ideal, sexless gods in some ethereal, eternal realm. Rather make one that could meet the unexpected and face the worst case, wade through mud and handle the traffic of the place we found ourselves in and whatever place might follow that, a system based on certainties but left options and questions open, which could only be made through trial and error, with hit or miss talk.

Not that we lived the lives of saints. When we had arguments, we fought robustly. Really, though, our fights were staged, and the roles we took in them quickly discarded. They were part of the process, not just a way of blowing off steam, but also of clearing the air and seeing our work afresh. Every now and then something new and useful appeared once the dust had settled.

This is what gave me hope starting out, that Unix is pragmatic, and skeptical about what it is supposed to be. Start with the solid, what you know, and build from there. If a plan doesn’t work, it doesn’t work, throw it out. But more, start somewhere, prototype first, get a program up and running, and save the fine tuning for later. Make sure a program does what it is supposed to do without worrying about what you can’t predict, yet at the same time leave room in your data formats and code for growth so revisions can be made later. Make it separate and independent, but keep its channels open so it can be modified later for other uses.

The result for me was that I soon quieted my doubts and wrote components I understood and could repair, then pass on with confidence. With confidence came growth. I found my place with the team and the place of my work within the system, then was able to move on from there.

The result for us was a system that was graceful, coherent, stable, and efficient, that could handle the rush of the present with less chance of crashing and was prepared to adapt itself to whatever the future might bring.

So much was already in place. The package we bought from Rosebud itself was a version of Unix developed at Berkeley, brought to Rosebud by grad students once there, and had most of the basic parts as well as a history of networking, an intimacy with TCP/IP, the protocols of the internet, with which the Berkeley system had grown up, with the blessings of the Department of Defense. Rosebud had ported it to the 386 chip so the system could run on PCs and added its own refinements. Other parts—a file system, a graphics engine for our user interface, an email server, other utilities, were freely available from the schools or other Unix firms. Or from open source, independent hackers who wrote from scratch Unixlike versions of their own to avoid legal hassles with AT&T, from whom we later got Apache, the web server then barebacking across the Internet plains.

So a great deal of our work was a matter of fine tuning and optimizing and adapting what was already there—speeding up file retrieval, tightening security, ironing out compatibility issues with the other platforms, other network systems, including our own, Summit, which posed the greatest problems—and filling in—writing drivers, an installer, and other odds and ends, and rewriting for Unix the directory services and the few other features we retained from Summit—and pulling all of this together and integrating it into a consistent whole, following open standards ourselves so we could stay with the Unix movement and not fall into proprietary traps.

As much our work was a matter of fixing appearance and giving definition, deciding what to show users and how it looked, setting the terms in their dialogs with the system—simple matters that proved not to be simple at all but presented challenges technical as well as those of logic and sense. It is not always obvious how to make obvious the obvious, and just as difficult to recognize what is subtle and has to broken down into its subordinate parts and given names. Terms, icons, the placement of commands in menus should follow practice, but where there were no strong customs we had to create our own, ones that were consistent within themselves and with what a network system had to do.

We kept as many of the current terms as we could and were reluctant to add our own, but still had to rewrite much of the language of networking as well as the special languages of Unix and Summit for Summix, coining words that were direct and generic and, if possible, concrete. We also tried to retain the look of Summit so Summix would follow Summit in orderly succession and maintain our user base. But we modified Summit’s pictures to match the common representations of files and folders and cursors that users now saw on their desktop systems, and we made its other icons refer to common objects. Where we couldn’t find an object, we threw the picture out and replaced it with a word. In the end, all we kept from Summit was its icon of a user, which we had a designer dignify, and its logo, the thick, black line of a mountain peak above the clouds.

The order of our design, in the layout of windows and the location of commands, reflected the order of what lay underneath, the placement and working of the parts, as well as gave users a picture of their place within the system to reinforce their sense that they moved in a system of order. But we also structured what we showed in levels, putting core services and basic commands on top, nesting beneath these the more complex preferences and functions so users could ascend Summix in steps. Our installer told them what was happening, what was being put where and why, and began to teach them what they’d need to know later, identifying settings and processes and the terms they’d see in dialog boxes, all of which was picked up and fully explained in our manuals. And we left the system open so skilled administrators could work directly on the shell and do with the system whatever they wanted. It was the one directive we got from Summit that we fully embraced, that we make a system easy for small firms and casual users to get up and running as well as one that could scale up and meet the needs of an enterprise. Our motives here were partly democratic, though probably as much still egocentric. With all the time we spent, we wanted to get Summix out there and make a presence.

We worked independently, separately, following the spirit of what moved us, taking on the projects that touched our special interests, our rare talents. It was being given this freedom that not only allowed us to work together but also find that what most moved us was doing whatever we had to do to get the project done, and we took on the tedious and trivial as well. In my case I tuned the virtual memory system for greater throughput, and took on a few other tasks of equal challenge. But I also spent a lot of time writing drivers for the newer network cards so they could ship with the package, as well as testing and debugging whatever was passed around—the same tedious work I had done before, but with this difference, that it had a coherent purpose. And I was involved in the interface sessions, working with the designers, from which, to my surprise, I learned a few things about programming I didn’t know.

Always there but invisible at our center, K, who did the hairy work of rewriting the hardware layer of the kernel for the 486 and Pentium chips, as well as oversaw the project, dividing and assigning tasks without telling anyone what to do. He was an architect in every sense of the word. In some people you can see buildings rising. In K you saw an entire city, flagpoles atop skyscrapers down to sewer pipes and all the connections in between. He had the whole design in his head and was attentive to the smallest detail. He could smell out bugs and sense ideas that wouldn’t work before they had been written. Rumor had it he could think in machine code. K inspired something close to awe, and even the best of us deferred to him.

Neither of which he would indulge, our worship or our respect. While he wasn’t self-deprecating, his terseness of words and manner and the utter absence of self-promotion gave that impression. In other ways he was strange, even for a programmer, ways that were hard to pin down—I never could remove him from the realm of Kafka. Yet the strangeness was not something that belonged to him but rather was what he held before him, something sizable and moving, that he couldn’t wrap his mind around or fit into a plan, yet still saw with precision and which somehow defined him, and sensing this in him moved me at least to withhold judgment of him, maybe judgment itself. Nor was he graceful in any sense of the word, yet he did foster a kind of ease. There was nothing about him to dislike, though I can’t say I especially liked him. Yet I liked not especially liking him a great deal, and while I never felt close to him he made me feel closer to myself.

But he did defer to us. He listened to our ideas when they were good, sometimes when they were not. Because he wanted us in on the planning and would talk to us about the overall design as if we understood, even if we didn’t. Only after we left him did we realize he had told us what to do, which we did. The temptation is to say that he was trying to validate our egos and boost morale, but again I suspect he was only being practical. Getting us involved and turning us loose was the only way the work would get done.

Not all the code we got from the other sources had been perfected, and what worked in Rosebud and the other Unixes didn’t necessarily work well in ours. Unix is a method, not a cure, for wallowing in the dark. The more heads you have working on a problem from different angles, the better chance you have of coming up with a solution. And no matter how well laid out the Unix procedures, a large part of writing its programs is still spent testing and debugging. Against the time needed here, the pressure from Summit to get Summix out fast, who along with NetWare was losing market share to Windows NT, barreling down the tracks. But the only way we could compete with them was to make a product that got it right, so we put in the long hours, gearing ourselves to a stepped-up patience.

So still and as ever do you have to manage and push, push the size of what you know and manage to retrieve it, push the limits of what you can produce, still have to focus and keep track of all the possible crossings of piled on bits of simple logic, keep track and handle all the breaks, the interruptions, and still find shortcuts but also watch for detours and dead ends and be prepared for the unexpected when a dash down a straight corridor leads to an unexpected crash, still and ever keep time with the processor’s accelerated beat while time slips away, weeks, months, years, even as you put more time in, the long days, the nights you slept on the floor, and yet but still have to stop time and debug, and stop and go more often, and stop and go faster, stop and keep debugging and revising and running builds and keeping track of versions and going back to an earlier one when the newer goes astray and debugging and revising and running until you see your way through a stuttering now—or stop once again and throw everything out once more and again start over.

I found out what K meant in his remark about my running, back when I first met him in the park, about how I kept my pace. Keeping pace, I discovered, is not so much a matter of reserve, of spelling yourself out to go the distance, but rather a kind of vision, the ability to see past present fatigue and through despair so you can stay focused and keep going. Distance is a state of mind, which can be altered. With Unix, I learned how to avoid going places where I couldn’t see what would happen or know how to fix when I got there. And I built a kernel of the self, a functioning core of mind and spirit that handled the basic tasks before me, and separated and protected itself from the ache of stress, from the noise of my confusion, the noise above.

Above, outside us, while Summit kept going downhill and while the state was still in another recession and its hills burned in summer and the burned-out hills flooded in winter and Californians moved out in U-Hauls or filled its prisons on their third strikes—we stayed put in our box on Bubb and kept on coding.

There wasn’t time, but still the questions came, how work might have changed me, what my effort was worth. The hours, the strain—what toll they might take. The narrow framework I had fit myself into so I could produce—how that shaped me and affected my life as a whole. Really, though, I didn’t have a good system of organizing my energies before, and with Summix I found a way to focus and get something done. And with the making and doing something right came a sense of completion, with completion, wholeness, with wholeness, restoration. Time and memory had come together and were making sense. My stomach healed and I felt stronger and more capable than I ever had before.

After a while, however, you don’t think about yourself anymore, but about what you’re doing. You stop wondering if you are good at what you do, but whether you are doing it right, even stop thinking whether you are good in any sense—or maybe this is what goodness is.

Then there was what we had put aside, the world outside our box, where it was going without us, what our work might worth to it when done. But there had to be some value, at least in itself, in our coming together, in forming a community that stayed together to make something well, and other value in what we were making, a network system strong enough to handle whatever faith the world might invest it.

And push, stay focused, and keep going, and at some point you reach a plane of abstraction where logic begins to glide and programming thrives. Push turns to pull, strain becomes the stress that purifies and charges. What came out of me the screen returned in an ever widening loop, opening up possibilities not just of our system but of systems outside of computers, of the notion of system itself and what possibilities a system might free—and I didn’t want to stop to sleep and when I slept I saw horizons spreading out and dreamed about what might lie past them and about flying there and when I woke I rushed to pick up where I left off and didn’t think about limits but what else I could do, what we could do, talking, coding, asking and returning, receiving and passing light in our windowless cathedral on Bubb from which the light of order poured.

When Netscape came out with its friendly browser in ’95, we all got a boost. PC sales took off once again, and we picked up the pace. Then the sessions with the tech writers, and with the testers, the revisions that came from these. Only silence from the brass at Summit, who now banked all their hopes on us.

Then the last stretch, the polishing and cleaning up.

In ’97 Summix shipped—

The trade journals praised it for its performance. On a 486 machine Summix marched in step, on a Pentium it waltzed across a network floor. The popular magazines gave rave reviews for its ease of use. Summit launched another large campaign, this one subdued and direct, which got a sigh of relief from the people who watched that sort of thing.

And Summix didn’t make a dent. The world had gone to Redmond, and wanted to keep its look.

Summit limped along for another year, then the music stopped. The firm went under, I got laid off, and was left holding worthless stock options.

Our careers and personal lives aside, I think our real regret was that our effort was to an extent wasted. There wasn’t any way we could have kept up with what Torvalds and thousands of open source programmers were perfecting on their own and giving away for free, Linux, then gaining market share and showing no signs of letting up, making Redmond sweat.

At least Marilyn and I had bought our house.

.

.

Two outs, but two on. Our pitcher, however, has been in control. He’s kept his head, his pitches down, and the first two batters hit grounders easily fielded. And while he walked the third and the fourth legged out a slow roller to short, he’s ahead in the count.

Now he pauses on the mound and stares off, with right hip hunched on his back foot, without question about what he has to do next.

Such confidence inspires, makes you take a breath and hold it. Maybe not that much, just enough for a kids game, yet not a copy nor its mask, not something he is trying on for size, but the thing itself, and possibly all he needs. And there’s nothing mysterious or ambiguous about it. Part of this confidence comes from the mind and body he got from Dad, but most of it has to be learned, and if learned enough times will grow strong enough to stay. And even though it may not make a difference, three runs down with two at bats left, what he gains here he will have later when outcomes matter more, or at least will help him face whatever comes.

And the team looks sharp, and have executed well behind him. Set on their toes and flexed, like the pitcher they are attentive to the moment, what it holds, what it can release.

Yet still nothing has gone to Allen. Though he leans into the game with the others, I don’t know where his mind is. He has his mother’s face.

.

.

.

Part 1 ↔ Part 2  ↔ Part 3 ↔ Part 4 ↔ Part 5

.

.

.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

What’s this?

You are currently reading Blue Skies / 2 at fictions.

meta