oscarbonilla.com

Or, how I learned the history of the computing industry and Unix by looking at the cover of a book.

Here’s the deal. For reasons best left unexplained, I have every edition of the Unix System Administration Handbook by Evi Nemeth, et al. I even have the Linux System Administration Handbook. Since every book’s edition is a different color, my daughter likes to play with them. The other day, while putting them back on the shelf, I noticed that the cover of the book reflects the history of the computer industry, the history of Unix, and a little history about Evi. So without further ado, here’s my explanation of what it all means. You’ll have to excuse the quality of the images, but I don’t have a scanner so I took digital pictures.

Unix System Administration Handbook, 1st Edition

This book was published in 1989. We see that UNIX system administration is a difficult topic. There is a Unix system administrator driving his car towards a cliff. I don’t know what the reference to cranberry bogs is about, but let’s focus on the colorful characters.

Starting rom the left, we have a dog named biff, which is a reference to the biff(1) command in Unix that prints a message to your terminal when you have new mail. In the center is a daemon, a Unix process that runs in the background. Since the daemon is showing us his watch, maybe it’s the NTP daemon? At the right of the daemon, you can see the finger(1) command, used to find information about a user and made famous by the Great Worm of ’88. I don’t know what the other two characters (the owl, and the cat, or is it perhaps a lady daemon?) are about. If anyone knows, or has a guess, let me know.

Unix System Administration Handbook, 2nd Edition

In the second edition, published in 1995, biff is dead (you can see the gravestone that says “R.I.P biff R.I.P”), probably replaced by POP. The cross behind reads “USL” and is a reference to the Unix System Laboratory at AT&T, the group responsible for System V, which had been sold to Novell in 1993.

In the front of biff’s grave, it says “Here lies the entire Berkeley CSRG”. That means the Computer Science Research Group, which was responsible for the development of the Berkeley version of Unix, called BSD, at the University of California and was disbanded in 1994.

The first edition of the book is being held by the paw of a cat. We can tell it’s the first version because it’s yellow, and it says “USAH”, short for Unix System Administration Handbook.

The dog, Biff, is now gone from the front row. He’s dead, remember? And has been substituted by a Monkey, a spider, and a Web. I don’t know what the monkey has to do with anything, but the web is clearly a reference to the World Wide Web, which was invented in 1993. The spider is clearly a reference to the web spiders, or bots that search engines use to index web sites. We can still see the daemon, the finger, and a new character, Dr. SNTPd, a reference to the Simple Network Management Protocol.

Note that the car is more modern, and it has the word “Unix” written on the front. Also the System Administrator behind the wheel appears to be a woman. Could this be a reference to more women in system administration?

Unix System Administration Handbook, 3rd Edition

The third edition, published in 2001, has many of the same symbols as the second edition. In this edition, however, there’s a new tomb. The Unix to Unix Copy Protocol, or UUCP, has died because most people use PPP by now. We can also see the second edition coming out of the grave being held by a tentacle.

Two more things should be noted. First, this is the first edition of the book to cover Linux, a newcomer to the Unix world, and you can see the Penguin in the co-pilot seat of the car. Also, the spider now has handcuffs, which might be a metaphor for the restrictions many sites started putting in place to prevent search engines from finding them.

Linux System Administration Handbook

This book came out in 2002, and was made specifically for Linux, which had by then surpassed in popularity all of the other Unix distributions. You can see the Linux Penguin driving now, and the sys admin as the co-pillot.

The spider’s handcuffs have been replaced by a shackle, meaning the restrictions on spiders are greater now. The other books are gone, as Linux has been declared the only winner.

You can also see that the sign that used to read “Beware! Vendor Gratuitous Changes Ahead!” has been replaced by one that has Unix somewhat deviated, but still going up, Linux going straight up, and XP (a reference to Windows XP) going down. The helicopter that is crashing also has XP written on it. The authors have no love for Microsoft’s Operating System.

There is also a penguin skiing on the mountain. I have no idea what that means.

The last interesting bit is that there is a sailboat in the back. Let’s take a closer look at that sailboat.

See the name on the boat? It’s the name of the main author of all the books, Evi Nemeth, who is now retired and sailing across the world.

Cool, isn’t it? Robert Langdon isn’t the only one that can find hidden symbols everywhere.

These are really good books by the way. You should probably get a copy of the Linux version.

I have to confess that I’m a beatlemaniac. I have every single recording from The Beatles, I have almost all the movies, I have documentaries, I have t-shirts that draw people’s attention and makes them strike conversation when I’m wearing them, I know most of the lyrics to most of their songs, I can even play some songs on the guitar.

Anyway, I’ve noticed an interesting phenomenon about John Lennon‘s life. When he was married to Cynthia, he was basically a good guy. I mean, he was a little crazy, but Cynthia, being very moderate and conservative, sort of kept him under control. On the other hand, when he was married to Yoko, he was out of control. He already had the tendency to do crazy stuff, but Yoko, instead of being the voice of sanity, encouraged him to be even crazier.

I’ve noticed that I have friends like this. Some of them get together with Yokos and it’s all downhill from there. Some others get together with Cynthias and they do pretty well. I guess it’s only human nature.

By the way, there are many other definitions of “the Lennon syndrome”.

Technorati Tags: beatles, lennon

Technorati Tags: windows

I’m sitting here at the Cocoa Heads meeting at Apple’s headquarters in Cupertino, and Scott Stevenson is talking about CoreData.

There are a couple of Apple employees here in the room answering questions, and from what I’m hearing, here’s my assessment of CoreData: stay the hell away from it. At least for a couple of years.

I’m surprised that people are still looking for the holy grail of data-driven applications: create them without programming. The problem is that this works for trivial applications. If you have any application that’s big enough, or popular enough that has to be maintained, these tools just don’t work.

I have yet to hear from an application built this way that’s easily maintainable…

Oh, by the way, CoreData’s NSPredicate class doesn’t support Outer Joins.

Now this is just stupid… two secretaries get into a flame war over a ham sandwich and they get sacked?

Talk about extreme disciplinary action! If I were their boss I would have just bought them both ham sandwiches and let them cool off…

I don’t know how people expect to have employees “not use email for personal purposes”. The whole idea about employee retention is that you want them to be as personal to the company as they possibly can. If they feel like they belong to the company, they will get personal.

I’ve been reviewing a number of resumes for programming positions because we’re hiring programmers and I’ve started wondering what it means to know a programing language.

For some people it seems it means “I can write hello world in it”, and they list dozens of programing languages. From a resume reviewer point of view, this makes it very difficult to see at what level the candidate knows a language. It’d be much better to list only a few and give examples of the programs built on those.

What I’m looking for in a programer basically boils down to this: “can they come up with general purpose abstractions that give the program a self-consistent architecture or do they copy and paste blobs of code to get the job done?”.

A few weeks ago I had to troubleshoot a Sun Ultra-10 system. Oh, the memories of working for a Sun Microsystems reseller and learning how to program in Forth. Anyway, as part of my debugging, I usually turn the diag-switch? to true in the OpenBoot prompt. What I’m saying is, I press Stop-a and at the OpenBoot prompt type:

ok? setenv diag-switch? true

Now for the catch. When you turn the diag-switch? on the output is printed in the serial console. This means the first serial port. If you don’t have a serial console, and you’re using the system with a monitor and keyboard, you’ll find yourself staring at a dark screen for a couple of minutes while the diagnostics run.

It’s really easy to think the machine is busted if you don’t know what’s going on. And that is precisely what happened to me.

Now for the punchline. Apple’s computers also use Open Firmware, the incantation is Option-Command-o-f. Once you’re in Apple’s OpenFirmware prompt, you can also turn diag-switch? on. Guess what happens… yup, a few minutes staring at a dark screen thinking the machine had died. Only Apple computers don’t really have a serial port.

I’ve been reading all the comments about the end-of-life of BitKeeper, the source control management system used by the Linux kernel developers. After plodding through hundreds of comments I began to understand how little the general public knows about the operation of BitKeeper and why having a free (as in speech) BitKeeper clone from anyone besides BitMover was a bad idea. Let me explain.

First, lets establish some context. According to this article, Larry McVoy had two reasons for dropping the free (as in beer) BitKeeper program: (1) Corruption, and (2) IP Loss. He goes on to explain how repository corruption would have caused major problems and how his IP would have been compromised by the free clone. Not many people bought it. To be sincere, I didn’t buy it at first, but after thinking about it and thinking about BitKeeper’s mode of operation, I decided that Larry McVoy is completely right. Let me explain.

Corruption

Here is Larry McVoy’s explanation of corruption:

BK is a complicated system, there are >10,000 replicas of the BK database holding Linux floating around. If a problem starts moving through those there is no way to fix them all by hand. This happened once before, a user tweaked the ChangeSet file, and it costs $35,000 plus a custom release to fix it.

Many people deemed this problem as a simple bug in the BitKeeper server. Others saw it as bad design. Few people understood that it was neither, and the corruption would have been inevitable.

Working with distributed systems is different than working in a client-server environment.

Client-server environments have a well defined protocol (or an API) used to pass data between the client and the server. There is a layer of abstraction between the data files the server uses to represent the data, and the data exchange that takes place. It should not be possible to corrupt the server’s data by using (or abusing) the protocol. Most of us feel really comfortable with this model. Most of the software in the world behaves this way.

Distributed systems (and peer to peer systems) behave slightly different. There is no server, and there is no client. Instead, a collection of peers interact by passing data between themselves. There is usually a protocol for transferring the data, and that protocol should have the same properties of a client-server protocol, but there is a slight difference. Each peer has a copy of the data files that in the client-server model belong only to the server. This is an important difference.

BitKeeper belongs to the second class of systems. A BitKeeper repository consists of not only the data (source code), but also all the metadata needed for revision control. Each user has a full copy of the repository, including all the history. There are two ways in which users can exchange data in BitKeeper: (1) clones, which amount to no more than creating a tarball of the entire repository and transferring it to the requesting peer (using, say HTTP), and (2) push/pull, which have some proprietary protocol for transferring ChangeSets between the peers. Note that these repositories contain all the internal data files that BitKeeper uses to manage the changes.

Now imagine a free BitKeeper program, let’s call it FreeBK (FBK). It is reasonable to assume that FBK will corrupt repositories. After all, it’s dealing with proprietary data file formats and its authors are learning, by reverse-engineering the data files, what are the invariants that BitKeeper maintains.

Now imagine a developer with access to both BK and FBK. This developer can clone repositories using either tool. BK will notice corrupt repositories and warn him. FBK however, still lacks the ability to detect certain kinds of corruption. If he chooses to clone a repository with FBK, the corruption has already spread. Working on top of this bad repository is fraught with danger. Work might be lost, bad ChangeSets could be spread (using either BK or FBK, as the corruption is now hidden under new ChangeSets), and information obtained from this repository can no longer be trusted (diffs and such).

If said developer has a commercial BitKeeper license, he will certainly call BitMover support and expect them to fix his corrupt repository and help him recover his work. In order to be able to do this, BitMover would have to track FreeBK and be aware of the ways in which it can cause corruption. This is clearly a very big support load for BitMover.

Loss of intellectual Property

The other reason Larry McVoy has for not wanting a Free BitKeeper program is loss of IP. The best way I can explain how this is a real problem is by comparing it to the PalmPilot.

When USRobotics came up with the PalmPilot, they had a very simple, but very important, insight: computers sucked at recognizing handwriting, but people are very good at learning how to draw new symbols. The Apple Newton had been a big failure, mainly because it never recognized what users wrote. The PalmPilot required users to learn a new simple alphabet, and that simplified the problem of handwriting recognition the point where the PalmPilot got it correct 99.9% of the time. This idea was very hard to come up with, and very expensive to develop, but once you have seen it done, it is obvious and very easily copied.

How is this related to BitKeeper? Well, anyone who has used BitKeeper knows that there are some ideas in it that are as simple as the handwriting recognition in the PalmPilot. Once you have seen them, they become obvious. Now, BitMover has already paid a big price for coming up with this ideas, and another big sum for developing them, but they are trivial to copy. You can see how it would not be in BitMover’s best interest to have developers of competing source control management systems using BitKeeper.

A BitKeeper Free Linux

Overall, I think having BitKeeper was really good for both the Linux kernel and BitMover. It gave BitMover much needed visibility when it was a small company, and it gave the Linux kernel developers a much needed tool when they needed it the most.

Like every relationship, there has to be about equal giving from both sides in order to continue. In this case, I think the breakup was inevitable as BitMover was giving more to Linux than it was receiving from it. I mostly feel sorry for all the small Open Source projects that used BitKeeper for managing their source. Also for those of us that used it for keeping personal files in single-user mode. We have lost a very powerful free (gratis) tool.

On the other hand, I feel projects like monotone, darcs, arch, etc. will get a much needed push by the community to produce better tools. It will probably take them a couple of years to be as good as the BitKeeper of today, and by then BitMover might have come up with a new and improved BitKeeper. But by then the open source community will have very good tools and people with money will be able to buy state-of-the-art tools. Isn’t that the way the world works?