The legend of Mt. Fuji

Twenty years ago, I was a promising young–and very unseasoned–columnist for a student newspaper at the University of Missouri–home of the Tigers–called The Maneater. Get it? Tiger? Maneater? Actually, healthy tigers never resort to eating humans, but legend has it by the time the founder learned that, the newspaper was already publishing and it was too late to change the name.

We were a ragtag bunch putting together a newspaper on a shoestring. Our computer network was quirkier than our staff, which took a great deal of doing–trust me, I’m used to being the weirdest guy in the room, and there I didn’t even stand out–but the piece of equipment that probably gives the production crew the most nightmares to this day was an old Apple Laserwriter–don’t ask me the specific model–named Mt. Fuji.Mt. Fuji, as best I can tell, spent its life spewing out cryptic error messages when it was supposed to be printing newspaper pages. I might have set foot in the production room three times in my entire college career, which is why I have no idea what model Mt. Fuji was, but Mt. Fuji’s legend couldn’t be confined to that small room. Mt. Fuji’s most enraging hits tended to get hung up as trophies in the newsroom itself, so we could all admire the spoils of war.

Truth be told, we probably could have wallpapered the entire student union with Mt. Fuji’s misprints, had anyone ever thought of it.

Some of my former colleagues were reminiscing about Mt. Fuji and its cryptic error messages. “Stack collision with heap!” one former colleague volunteered.

Talk about two worlds colliding.

Really, two worlds colliding. In 1994, I had no idea what that meant. The 2014 version of me, however, knows exactly what it meant. You see, on my way to trying to become a journalist, I took a couple of jobs fixing and upgrading computers, and by the time I was a senior I had worked my way up to being a network administrator. And when I graduated with a journalism degree, I kept right on being a junior network administrator, taking the work nobody else wanted, which was mostly security work. After about 10 years my knowledge of security propelled me to the level of senior administrator, and later into pure security roles, but to get those roles and keep them, I had to get certified. Which meant passing a big nasty test covering a lot of things, including a little bit about computer architecture.

You know, microprocessors, memory protection, indirect addressing, stacks and heaps…

Did somebody say stacks and heaps?

It helps to understand that laser printers are computers. The laser printers of the 1990s were often more sophisticated than the computers we connected to them, which was why they cost as much as a car. When you laid out masterpiece pages with Pagemaker–bite my tongue–or QuarkXPress–what real men and women used–and hit “print,” what really happened was the computer would write a program to render what you drew on the screen and send it to the printer to draw it with higher fidelity.

Or, if something went wrong, you’d get an enraging error message.

Think of the heap as ordinary memory. Programs use it until they don’t need it anymore, then they release it so the computer can reuse it. It’s necessary but it’s nothing special.

The stack is sacred. That’s where really important information goes, and there are rules about how you put stuff on it and take stuff off it. Break those rules and the world as the computer knows it can end. I’m simplifying things here, but trust me–calling the stack sacred is, if anything, an understatement.

A well-designed computer system keeps the two things separate. Mixing the two up is as bad as that crude army drill sergeant saying about not knowing your [excrement] from Shineola. You don’t want to polish your shoes with something you found in a toilet, and then go get married.

Mt. Fuji may have done a good enough job of keeping them separate when printing invoices or recruitment letters, but we had some ambitious designers, and it didn’t keep up with them very well. What surprises me is that Mt. Fuji was smart enough to stop and print an error message when the stack and heap collided, rather than spewing page after page of garbage.

But if you’ve ever seen a Blue Screen of Death or a kernel panic, that’s exactly what Mt. Fuji was doing.

Computers are better at managing memory these days–it’s a necessity to protect humanity from the wrath of the people who supervise me–so we see fewer blue screens and kernel panics and stack/heap collisions today than we did then.

And, come to think of it, maybe the problem with Mt. Fuji was just that one of its memory modules had gone bad. That would explain why it could detect when the two collided, but couldn’t prevent it. It’s a shame that in 1994 I didn’t know enough yet to put that together. But for all I know, someone else may have thought of that and tried, and failed.

We can look back and laugh about it now. Some of us, at least.

OK, maybe us writers, who only saw the error messages long after the paper had gone to press and the production crew was in bed. From what I understand, the production crew still suffers from PTSD.

If you found this post informative or helpful, please share it!