First-Hand:Sun Microsystems’s Storage History – The Early Years

Sun Microsystems’s Storage History – The Early Years

An Interview Conducted by Tom Gardner of the Silicon Valley Technology History Committee, IEEE Santa Clara Valley Section, for the IEEE History Center.

18 December 2024

ABSTRACT Sun Microsystems' commitment to open industry standards and low-cost volume peripherals caused it to support and rapidly adopt a multitude of standard storage interfaces. Four key developers of Sun storage products, Andy Bechtolsheim, Mitch Bradley, Rich Clewett and Tom Lyon are interviewed on their roles in early Sun storage development; this interview mainly covers activities into the early 1990s. Its initial storage offerings in June 1982 included a half-inch reel to reel tape drive and two SMD hard disk drive options. In 1983 Sun introduced new deskside systems with 5¼-inch disk drives which attached through the Small Computer Systems Interface (SCSI), the first computer company to adopt SCSI in its product line. During the following years it supported the development of and/or offered products using interface standards such as ESDI, IPI, Fibre Channel, and SAS.

This transcript of the interview has been edited for readability. Brackets indicate where misstatements have been corrected and/or new material has been added. A highly edited recording from which this transcript was created is available here. The original unedited recording is available from the IEEE History Center as: “SunStorage 20241218 TEG1_1414x864.mp4”

Time stamps in the form of [hh:mm] are rounded to the nearest minute but are approximate due to editing of both the recording and the transcript.

TRANSCRIPT

[00:00] Editor’s note: This interview covers Sun Microsystems' storage history into the early 1990's. Sun alumni interviewed today are:

• Andy Bechtolsheim, a founder of Sun,
• Mitch Bradley, Sun Senior Staff Engineer,
• Rich Clewett, Sun Director, Storage Systems and
• Tom Lyon, Sun Distinguished Engineer.

TomG: Hi, I'm Tom Gardner. I'm a volunteer at the Silicon Valley Technology History committee and the Computer History Museum. Today, we're here with a group of Sun alumni to talk about the history of storage at Sun Microsystems.

Sun Microsystems, of course, falling into both Computer History Museum and the IEEE Silicon Valley History Committee interest.

Sun's initial storage offering was [in June, 1982], and it included two high-end storage products, a high-end tape drive and a high-end disk drive. A [year later, in 1983], they introduced two low end products, both of which attached through the Small Computer Systems Interface, SCSI, as those in the art like to call it.

SCSI grew over the years, as did Sun storage products. And, ultimately, SCSI came to dominate the storage product line from Sun and other companies in the computer business.

By 1997, Sun's product line has expanded quite a bit.

By my count in this product planning document from 1997, there were 31 desktop products and 27 server products.

This interview explores the first few years of the history of Sun's storage with four key developers. Each one of them will have a few minutes now to tell us a bit about their personal history at Sun, and we'll do detailed full history experiences interviews separately.

I'll have each one introduce himself individually, starting with Andy.

[00:03] Andy: Hi. I actually worked on the original Sun workstation at Stanford before Sun was incorporated. The original product plan for the Sun workstation was to be diskless, meaning to have no disk storage at all, because at the time, in 1980, there was no suitable form factor disk drive that would be commensurate with the requirements of a 32-bit microprocessor, such as the 68000.

They would have an Ethernet connection and then access storage from a centralized file server -- we were a little ahead of the future here -- so it wouldn't require local storage. Remember, at the time, the Apple computer had a five and a quarter floppy disk drive, which was completely useless for 32-bit computing, and the whole notion of storage small desktop kind of machines, there was no suitable product. The SMD drives were 14 inch size and didn't have much capacity and had some bizarre interface.

So it wasn't actually until Sun was incorporated, and customers demanded a way to back up the data and attach storage to the Sun workstations and servers they were starting to buy, that we had to actually connect the disks.

I think at the earliest time it was in fact the SMD interface, there was a company called Xylogics who built this Multibus card, a fairly expensive card, to hook up the disk drive, and luckily we had a Multibus standard bus so we could plug it right in, and there was a device driver on a Berkeley UNIX and it actually worked.

[ The device driver was written by Tom Lyon ]

[00:04] Andy: That was around for a while, but that form factor wasn't suitable for the desktop or deskside workstations, which Sun also was building. The disk just didn't fit in.

And then, there was an early next generation storage devices from [Seagate], at the time, the five and a quarter form factor, which had the precursor to SCSI.

And I'm sorry, I don't remember all the interface history exactly of what the name of that interface was, but we were one of the earliest adopters of making that work in conjunction with the Sun products, and it worked, of course.

Then, over time, that evolved then into the smaller three and a half inch form factors, which came out much, much later. I would say in 89, I believe, we started shipping those in volume, and then, of course, there was standard SCSI and so on.

But there was this very interesting time in the 1980s where we basically adopted every upgrade and generation of hard disk interface, and made that work in conjunction with Berkeley UNIX. It all shipped, and it all got delivered, and customers were happy, and we were happy, and everybody was happy.

It was actually amazing in retrospect that these interfaces, as they evolved, got incorporated in all these multiple generations of equipment, and it solved the problem at hand.

So that was my quick story. Obviously, much later, Fibre Channel showed up, and much more advanced storage arrays got introduced.

But the first 10 years was really attaching either a few or a larger number of disk drives to these Motorola based systems, and later to the SPARC systems. As the systems became more powerful, they could support much larger file storage and file server applications. And then, with the NFS protocol, we could actually deliver the concept of diskless workstations where the server had the bulk of the storage. But as disks got cheaper, it was obviously practical to add disk drives to every local workstation, like people have today, to do the local operations.

So that was a short introduction perhaps, but others here can speak much more eloquently to the exact generations of interfaces that the company went through over all these years.

[00:06] TomG: I think chronologically probably next in order is Tom .

TomL: Okay. I was hired into Sun as a UNIX guru, you know,

I've never gotten any fame compared to Bill Joy in that respect, but I actually started a couple of months ahead of him.

I actually got started with UNIX in 1975, and it was a project at Princeton to port UNIX to a mainframe computer. That kind of continued on and off until I got hired at Amdahl, where we really made a product out of it.

So I was coming from Amdahl to Sun, and by then I had a huge amount of experience writing device drivers, because everything was different on mainframes, and so I became jokingly referred to as Director of Devices at Sun for the first year or so and, most notably, the SMD storage, the Pertec half inch tape, and that kind of stuff.

I want to correct to your timeline a little bit, Tom, because we definitely had disk products in 1982, but they were pretty much off the shelf. We had the CDC Lark, and the Fujitsu 80 megabyte drive, I think. I saw somewhere a price list from summer of 82.

The very first win I had at Sun was fixing a bug in the Interphase 2180 device driver, so that the version 7 UNIX that we started with would be a lot more stable.

[00:08] TomG: Both drives, I believe, were SMD-interfaced products.

TomL: Yes, the first ones were SMD.

TomG: To me, that's a high-end interface, although Lark certainly is not a high-end product.

Editor‘s note: The CDC 9455 "Lark" was a 10 MB disk drive with 5 MB fixed and 5 MB removable in an 8-inch cartridge that OEM'ed for $2800 in quantity 100 [per DiskTrend]. The cartridge had an estimated retail price of $100 [based upon $140 advertised retail price of 25 MB cartridge].

TomL: And then, after the first year or so I really didn't have much to do with storage anymore. I became a networking -- especially non TCP/IP -- networking guy.

[00:09] TomG: Going in chronological order, is Mitch.

Mitch: Okay I got introduced to UNIX when I was an intern at Bell Labs. And then, after I graduated from undergraduate, I went to Cambridge University for a kind of interim year, and they had gotten a new PDP-11. It was running one of the DEC operating systems, and I kicked and screamed until they decided to switch to UNIX, and spent about a year trying to bring that thing up, and so I was kind of a UNIX fan.

Then I went to work for Rolm Corporation doing analog circuit design, but I always wanted a UNIX machine of my own. I went to Stanford to try to find a 68000 C compiler at the behest of a guy I worked with at Cambridge, and met Vaughn Pratt, who showed me this prototype of a Sun, and I wanted one.

So I got in contact with Andy and got him to give a presentation at Rolm, and then I started angling for a job at Sun, and eventually got one. I applied to both the software group and the hardware group. I got a rejection letter from Bill Joy, but I already had an offer letter from Andy, so I made my way into Sun in the fall of 82, just after a five for one split of the stock.

My first role at Sun was doing a hardware design for I/O. The first such design was the SASI controller, which was a Multibus card, and I guess that shipped on the Sun-2/120 Multibus system.

Then I did Ethernet controllers, and then transitioned into kind of a debugging role. I had expertise in both hardware and software, so I was particularly adept at the problems where nobody really knew exactly where to look. It's like you kind of cross the boundary between the hardware and the software.

In that role, I ended up writing diagnostic drivers for just about everything, and debugging the strange problems that were kind of puzzling because they crossed the boundaries.

Later I became the leader of the firmware group, having developed a new firmware system for the SPARCstation that became an IEEE standard. In that context, that's related to the SCSI since all of our I/O had sort of SCSI at its core, I had to develop a library that would be adaptable to a lot of different SCSI systems. That turned out to be very useful later when the IEEE firmware standard was adopted by IBM and Apple, [that is the IEEE 1275-1994 - IEEE Standard for Boot (Initialization Configuration) Firmware]

[00:12] Mitch: especially since Apple's products were SCSI-based as well.

Another interesting thing is that the SCSI common command set lives on today, embedded in all kinds of things like USB flash drives, so there's a SCSI layer inside just about every storage thing there is, at the Common Command Set level.

TomG: I think that leaves us Rich.

Rich: First of all, thank you for putting us together. This trip down memory lane has reawakened a lot of...

TomL: It's a trip down storage lane.

Rich: [Laughter]

Well, storage was my life for a long time. So I joined Sun in 1984, just before Christmas, and I inherited a lot of things from the three folks that have already talked here.

My background was coming from controller design. I had graduated with my master's from Santa Barbara in 1975. I worked for a semiconductor company on microprocessors for two years, and then I joined my first startup called DSD, Data Systems Design, and that's when storage started for me. We did controllers for 8 inch floppy disk drives from Shugart, to begin with, these large things in a cabinet, then the same form factor became 8 inch hard disk drives.

Before joining Sun, we had a group that I led that designed a Multibus controller that talked to eight inch hard drives, plus QIC-2 tapes, plus floppy, in one slot. Around that time, we had released that controller, I was told that there was a guy at Stanford that was doing some work that was interested in a Multibus controller to talk to disk, and attach it to his workstation. So I actually met Andy in Margaret Jacks Hall when he was a grad student and saw this thing that he called a Sun workstation, Stanford University Network, and it consisted of a monitor that was above his desk, a whole bunch of wires, a bare board and a Multibus card cage someplace. But it was very impressive, because you looked at the monitor and you could see instead of little ASCII characters, you could see a very nice script, you could see drawings.

That was followed by a discussion of whether we should have intelligent devices connected to disk that would push information into memory, or whether the powerful CPU at the center should pull information from these devices. That debate continued for decades, the centralized versus distributed model on how much to trust storage, versus having the CPU control everything.

So that was an early experience with Andy.

Also around the same time, we had visited Xerox PARC who had the Alto machine that was connected to a disk pack drive from Diablo that was attached to the workstation. There was a high resolution monitor, and a mouse, and other attributes, and that preceded the Sun. At some point, I would enjoy hearing Andy's comments on the things that influenced him from that connection.

A couple of years later, in 84, I was ready to leave the company that I was at, and I heard that this new company Sun, that I was familiar with, was looking for somebody to handle all these storage issues that were so annoying for all the software folks, and deal with vendors, and get the product out, get things up to production. And I was intrigued. I thought it was probably a crazy place, knowing about the background of Bill Joy, having met Andy, and hearing stories of the company nearly going out of business due to exotic monitor problems and other such things. They had this 30 year old guy, Scott McNealy, that had just become CEO, after his predecessor.

I went there for what I thought was a practice interview, because I was curious about how they were faring and whether they were really going to survive at that time.

There's a longer story, but the short version is, my first interview was with Bernie Lacroute, who had come from DEC, being the VAX product manager. He is running engineering. He said, we got all this stuff that needs to be done. I said, I'm a designer. He said, it's easier to do that once you're inside than coming in from the outside. I interviewed with Bernie. Eric Schmidt was running software. It was a good view in. I was definitely intrigued. It was clear that they were headed for an IPO sooner rather than later.

My final interview was with Scott McNealy. I was in a conference room. He came in, and his first words to me after sitting down was, "You want to ride a rocket?"

And, the rest is history.

I joined Sun just before Christmas. My wife and I went to the Sun Christmas party in 1984. We sat at a round table with 12 or 13 other people. The first couple introductions, we said, I'm brand new, I just started, I don't know anybody. More than half the people at the table said, we were also just hired in the last two months, we don't know anybody either. So it was a really interesting time of rapid growth.

With Tom Lyon, Tom was very relieved to have somebody to hand off all this stuff to. I remember that clearly.

[00:18] TomL: I have a hard time believing I made it all the way to 1984 doing that stuff.

Rich: Well, you were the guy. SCSI was just happening. We'll get into the timeline, but the Sun-3 was getting ready to be introduced. You had a real product. You had these high-end drives. There were lots of issues to deal with, and we did tons of qualification.

So that was the start. I built a storage group. I started with one technician. We brought in people to do drive qualification, and make these things work. The MTBFs were about 4,000 hours, on a good day, for drives. That's what? Half a year.

Then, we got into the design business. We hired some designers. I guess first we did asynchronous multiplexers, so that you could run a bunch of terminals in a time sharing mode off of a server. We did IPI design, eventually RAID, Fibre Channel, and other things.

So I dealt with storage for a long time. I had to apologize quite a bit every time something failed. We had relationships with many, many different drive vendors. We eventually built up capability so that we could do torture testing of these drives to make them fail.

When I looked, a decade later, Sun was over 10 billion dollars . Storage was maybe 20 percent of that, and it was a big business.

So the company grew from 200 people or so when I joined, to quite a bit larger, and I stayed with storage until leaving right after the dot com bust in 2002.

[00:20] TomG: Let's start walking through storage history, walking down the memory lane, so to speak . The first product, Sun-1. Mitch?

Mitch: I did the first SASI controller, but I wanted to just comment on something that Rich said related to the near death experience. We had a lot of near death experiences, but one that particularly comes to mind was, we were very successful at selling products, but not very good at delivering them, or at quality. It became a crisis and Scott, or maybe the whole exec staff, decided to create a team to go out to talk to the customers and find out what the top 10 quality problems were and try to address them.

One of the things that I particularly remember. I was the hardware engineering member of that team. We were in Boston, I think at Computervision. We were in a round table, and one of the customers kept asking could they get a flaw plan of the disk? We said, well, I mean, there's a defect map on the disk. It is a documented place, and you can read it off. We kept talking around it. He said, no, a flaw plan. We eventually realized that it was the Boston accent, and he meant a floor plan, so he wanted to know the layout, where everything was.

[00:22] TomG: Actually, I think it's probably Tom's experience with the variety of SMD controllers, before you guys got into doing your own hardware piece back, on the Sun-1. Am I correct about that, Tom?

TomL: Certainly the first year or so it was throwing together whatever we could find on the street, in terms of SMD and shipping it.

One particularly funny episode... We had the CDC Lark, which was a 5 plus 5 drive, 5 removable, 5 fixed, and that was barely enough to run UNIX. But they came out with a 25 plus 25 and they brought it over, an early prototype unit. This would have been late June of 82.

They said, please take good care of this, we'll give it to you for a few days. The next day it was checked as baggage on the airplane to Boston, because we were having a trade show there,

Editor‘s note: Summer USENIX 1982

TomL: worked fine.

[00:23] TomG: There was also an 85 megabyte Fujitsu, I believe,

TomL: Right, which was a very nice drive, but pricey

TomG: That leads to the Sun-2, which is the beginning of SCSI, or SASI, and Mitch, am I correct? You designed the adapter?

[00:24] Mitch: That was the first thing that I designed when I started at Sun, and it was pretty nascent at the time. People were just kind of talking about it, and there was very small number of products available.

There was talk of SASI, of course, the Shugart Associate System Interface, but they were trying to standardize it, and so they couldn't use the name Shugart. They changed the name to Small Computer Systems Interface, and they wrote the SCSI spec with some fallbacks to the existing practice that existed in the Shugart version of it.

We implemented the SASI subset initially, because there's really no point in the complexity of the disconnect, reconnect, and the arbitration, given that we didn't need multi-master capability, and there weren't really any storage products out there, that really supported the new features, so we went for the simplest subset possible to try to get the thing out into the market.

I designed that board. It was a Multibus board, and it also had four channels of extra serial interface, so you could hook it up to modems and stuff like that. Later, the core design for that, SASI interface, I believe, was incorporated onto one of the VME cards, and that had a little bit of life to it before we needed to support the disconnect, reconnect. And Serdar I believe designed a board based on the NCR chip.

TomG: Tom, I believe you did the driver for that?

TomL: Well, Mitch is always accusing me of doing drivers for things, but I actually don't remember doing the driver for SCSI, although I certainly discussed the board architecture with Mitch.

[00:25] Mitch: I'm pretty sure you did that driver.

TomL: Yes, I did a lot of drivers. Oh, man.

Mitch: Who else would it have been? I know the very first driver I did was the LANCE Ethernet, which was much later.

TomL: I definitely did the serial port drivers for the serial ports on your card.

Mitch: The driver wasn't very difficult. The interface was pretty simple. It did need a state machine to handle the SCSI phases, but it was not a complicated design.

TomG: Remember any issues about mixing SASI and SCSI on the same host bus adapter?

Mitch: I remember the way the hardware worked. You could just ignore the SCSI features. If you didn't assert the arbitration line, or if you asserted it in a certain way, it just fell back to the SASI subset. There was an ID, and if the host controller asserted only the target ID bit, then it was basically SASI mode, and if it asserted both the host adapter bit and the target bit, then it was SCSI mode, and things were supposed to fall back, and they pretty much just worked, because the protocol was pretty well designed.

[00:26] Rich: It was a very constrained environment as I look back at it. You had a single host. You had a bridge board from Adaptec that was talking to the ST506 device. The tape was handled on a separate Multibus board, that had been developed earlier, so you didn't mix disk and tape in the early days. You were running asynchronous at a low data rate, so you're just looking at one thing, and either one or two disks, hopefully from the same manufacturer.

Later on, when we had SCSI boards from Emulex, there were some limitations in mixing the Emulex bridge board and the Adaptec bridge board, with things stepping on each other, and that got more complicated. But I think it's been stated before, the main thing in early Sun was you just had to make stuff work.

A lot of that applied to the SMD area, where it was just trying to make SMD work with some controller that was stable. And, the same rule applied to SCSI.

[00:27] TomL: Although we viewed the configuration as pretty simple, the most common problem we would have is people bringing in stuff they had only ever tested on a PC, or some micro, where the entire software stack and I/O was all totally synchronous, one request at a time. As soon as you introduce any asynchrony, or queuing, in the device, then things went to hell in a hurry, and the UNIX system really hated that.

[00:28] Mitch: I remember debugging a Xylogics board problem.

At one point we were having these very low frequency failures with the Xylogics SMD card, and I spent quite a long time trying to debug that. I finally managed to write a diagnostic that would, instead of failing once every two days, it would fail once a second. At that point, I was able to discover that there was a bad synchronizer in the bus interface for the command register. Sometimes, you would write to the command register, and it just wouldn't take the write. That was a really kind of common problem back then, synchronization problems. And, interestingly, Andy's PhD was on the topic of synchronizers.

Andy: Which I never finished.

Rich: Yes. I wanted to comment on drivers a little bit too, in terms of my experience coming in at 84.

It was hard to get support from software on this boring and buggy area of storage. When I had questions about the vendors that we inherited, Fujitsu was a major vendor of this, I would ask Tom Lyon. about the vendors. But if I had a driver question, it would go to Bill Shannon. He was the best driver guy ever, maybe except for Tom Lyon, but he was the expert, so I could get an answer. But very quickly, the support went to whoever the newest software hire was, that couldn't work on NFS, or the UNIX kernel, or the sexy stuff, yet.

And so we had to isolate ourselves, as much as possible, from software bugs because it was hard to get support to debug and fix them, or add features, so that was a factor in some of our decisions is to have vendors debug things, and do the testing, and deal with the multiplicity of drives, so that we could have a very stable software interface and just talk to one controller, no matter what was behind it.

We used just drives from..., early on, it was Maxtor and Micropolis[.]{.underline} We had Vertex, we had Quantum, we had Seagate, we had Toshiba, we dealt with everybody. Isolating ourselves from the drive-specific issues, and having somebody else put in the manpower and the effort and the debugging. It was a strategy that helped us keep the production going.

[00:30] TomL: One particular low point for me in the non-SMD world, I forget whether it was early SCSI or something different like ESDI, but a field engineer from a disk company came in for me to try out a new drive, and surprise, surprise, he brought the President of the company with him. It's like, Oh, that's cool.

So I plug it all in and the drive doesn't even spin up. It's like, okay.... You know, we had quality problems.

[00:31] TomG: Do you remember the company and the president?

TomL: Fortunately not. Otherwise, I might slander somebody.

TomG: SCSI, just as the Common Command Set tried to come into existence. Any issues there that you recall?

Mitch: I remember being very excited about the Common Command Set, because it was very tedious having to deal with all of these different command sets. I remember the CCS seemed to me a little overly complex, but nevertheless, the promise of not having to keep dealing with all these silly minor variations seemed like a, a good thing.

And, as I mentioned before, it turned out to be something that really ended up having a lot of legs in the industry.

[00:32] TomG: It exists today, right? As somebody said, in a SCSI layer in almost everything...

in everything!

So the next step was you abandon ST506, and picked up bridge controllers for ESDI[.]{.underline} Any recollections as to why and how and who? Or any problems? That would be October 86.

Rich: It was just part of the natural evolution. We wanted to follow the capacity curve. This was becoming individual storage. So as they gave you capacity, it also was more robust because you got the phase lock loop over on the device rather than on the host side. So we got robustness out of it, we got some speed out of it, it was just a very natural piece.

But the ESDI controller was also the SCSI controller. I'd have to look at the date, but I think you had ANSI SCSI very close to approval, or approved, when we used the Emulex bridge board at that point to talk to disk. We still had a bridge board, we still were having the vendor do all the debugging of stuff, but it was the next capacity and the next level of speed at a similar price.

[00:33] TomG: I'm very interested in the decision on the Sun-2 to go to SASI / SCSI as opposed to the other alternative interfaces that were being pushed by both companies, . Priam was pushing its own proprietary interface, and you had the ANSI committee pushing IPI. Anybody recall any discussions? Why SCSI versus the other intelligent interfaces? Or, why not continue the architecture of the Sun-1, where you had a separate Multibus or separate VME controller for each type of interface, one for hard disk drives, one for tape?

[00:34] Andy: I can speak to that. The highest volume Sun-2 was actually a single motherboard computer that was no longer a Multibus cage. So without the Multibus cage, of course, you couldn't plug in any of these Multibus type SMD controllers, and furthermore it was too expensive, besides the fact that it didn't plug in. We really wanted a thing where you could attach an external device with less amount of logic, some logic that we could integrate with that system more concisely.

What I remember is that even at the time we perceived the simpler SCSI or SASI interface at the time to become a multivendor supported industry standard. And, of course, Sun was always all about industry standards and multiple vendors, which would also solve the problem that, if one disk supplier couldn't deliver, or the disk drives didn't work well, we could then switch to another disk supplier.

So this notion that there would be multiple disk suppliers delivering a product that we could plug in there, and negotiate the best price, or find the one with the best reliability, was a compelling argument about buying luxury drives from Fujitsu, or any other high-end technology that worked, but was very expensive.

And thus, the direction towards SASI and SCSI later was, I would say, dialed in. It became the volume standard.

[00:35] TomG: Did you consider IPI at the time, that was being pushed?

Andy: All I remember was that IPI was much more complicated and we couldn't get, reduce it down to our own implementation controller, and we were stuck with buying a multi-thousand dollar card from somebody, which was a significant part of the overall product cost.

TomL: I wanted to mention that, even with trying to ride the cost curves down on these smaller drives and cheaper interfaces, it was still very, very important for Sun to have the diskless workstation support, because that let us come in at a very low price point for low end seats.

[00:36] Rich: In terms of the choice, there are also some connector studies, where there is limited connector space on the CPU board. With one connector, you could have all these different current and potential devices.

Also to comment on the multi-vendor. We dealt with so many vendors because, number one, some of the vendors didn't work.

Andy: Yes, it was hard enough to find one that actually worked well, right?

Rich: So that, that was one thing that we continually dealt with. Their schedules were different, so the availability would differ. The prices were different. If we had two that worked, we had a choice there.

Then, as Sun became bigger, it was a matter of volume. We would find that sometimes one vendor couldn't give us all the product that we needed. This complicated our life in storage. It was always a matter of finding something that worked reliably, pushing the work onto the vendors to prove that the stuff wasn't going to fail in the field, and then ramping it up like crazy, and then doing it again.

[00:37] TomL: I think this is when Andy learned how to push vendors to their limits, which he continues doing today.

Andy: We just needed the product, and some vendors were better than others. If you look at the industry today, there's two surviving hard disk vendors, but of course a lot of that went to flash now.

But still, in the end, the ones that could deliver and scale were the winning vendors, and everybody else just fell by the wayside.

Mitch: It's also important to realize the transition that chip technology was taking at the time. Tom, there was a paper called 'All the Chips That Fit'. Was that you and Shannon?

TomL: It was Joe Skudlarek and me.

Mitch: Okay. At this time, the predominant technology was DIP packaging and Small Scale Integration, but LSI was starting to happen. It was package limited and the technology for making boards with the fine pitch packaging was just in its infancy. We're always facing board real estate problems because 20 pin DIPs were large compared to their functionality. There were connector pin out limitations on the back plane, and connector size limitations, as Rich mentioned, for the external I/O.

So there's always this big balancing act about what you could cram on the board, and what you could get off the board.

[00:38] TomL: But also the opposite, though. If you found extra real estate on your board, in your design, there was always something else you could fill it up with... more memory! But that made the software configuration a lot more complicated.

Andy: Right.

And, with SASI going to SCSI, there were becoming single chip customized implementations available, which took very little board space compared to the traditional high-end disk interfaces, so it was compelling to add that interface to the board because it fit easily, it didn't take much power, it was low cost, and, you had your local disk drive or tape interface.

There was just no alternative to this. It was completely obvious that this would be the volume standard on the workstation side. As we moved away from the deskside chassis, there was no more card cage that would allow us to plug in a Multibus or a VME bus full adapter.

[00:39] Mitch: It was especially compelling with these chips on a single board, because otherwise you ended up with this highly functional single chip just completely surrounded by bus interface logic.

Andy: In fact, I seem to remember that in, I think it was 84, it seemed to me that the only reason we were building these Multibus or VME rack chassis for the desk type application was for the disk controller card, and that once we had the disk interface on the single motherboard, we wouldn't even need this whole bus interface anymore.

Mitch: Except for the case when you needed a lot of serial ports for like a server.

Andy: Yes, there was server applications, which were different. So the desktop and the server in a sense diverged to that point. For the server, you want as many slots as you can to add as many interfaces, but on the desktop, it was really with the Sun-3/60, it was all single motherboard, all the volume products became single motherboards.

TomL: My home machine for a while was a Sun-3/160, the original big VME chassis, but with an additional chassis the same size with the SMD drives. So, big home machine.

[00:40] Rich: I'd like to introduce another element in all of

this, and that is that Sun, from the beginning, always had Ethernet, from the very first model on. That meant that it could operate the client server architecture.

And then, shortly after I joined, NFS was announced, and so you could remotely mount your storage, and it meant that the desktop had two different modes. One mode was you had something that was just good enough to get the job done, and the other mode was you were a superuser workstation, and you wanted the most power as possible right beside you.

With the SMD and the follow on there, we had the powerful stuff for the server. You had your tape player, you had this noisy stuff, you had these big disks, you had these 10 and a half inch Super Eagle from Fujitsu. That was all on the server side, and that was fast.

On the desk side, you could attach the SMD. The Sun-1, on your desktop, had four SMD connectors. You could attach four disks to this box that was sitting in front of you, if you wanted to be the superuser. But if you didn't, and you wanted your personal storage that was local, you wanted something that was cheap and small, didn't have to have a high capacity, because it was just for you, that's where SCSI just fit right in. It was good enough.

[00:41] TomL: It's interesting to contrast that, though, with what was going on in the PC world. where there was, of course, even greater pressure, but they ended up getting rid of the controller entirely and running the AT bus to the drive.

That was an architectural disaster, which lives on as SATA.

Andy: Actually, that discussion's a good segue into the first embedded host bus adapter, which I think occurred around 1988 with the Sun-3/50. Is that correct?

We did some early LSI logic with a fairly small number of gates, but it turns out one of these SASI type interfaces was actually very low in complexity compared to current kind of interfaces today, so it was straightforward to merge the whole thing down to a simple ASIC that LSI could make at a very low cost, and it fit right on the board, and there it was. Every machine had one.

[00:42] Andy: That was carried forward in the SPARCstation 1 and all the future products. Once it became a part of an ASIC, on the board, it was, I wouldn't call it free, but it was just bundled in, just like Ethernet was always bundled.

Rich: Let me go back just a little bit. As I mentioned earlier with the desktop, the Sun-2/50, which replaced the Sun-1 on the desktop, is diskless. There was no internal storage, there was no external storage. Even though you could have done it, it wasn't offered. And so when I joined, there was this great demand from customers that said we want something of our own.

If I have the timing right, over Christmas vacation, Bernie Lacroute came up with a whole product line that I believe became the Sun-3, or the successor to the Sun-3. I used to have a document that was hand drawn that showed that there was a desktop machine attached to a shoebox, and there was a deskside machine, and it had its storage, and there was a server, and then there was a dinnerbox and there was a lunchbox, and, you know, it was probably a 15 page document, and he said, this is what I worked on all Christmas vacation, and this is what we're going to do.

[00:43] Andy: I contributed to this too. So the lunchbox, just to decode this, is a single disk drive. The dinnerbox was multiple disk drives in one plastic package, so they would share the SASI connection there. And they both were very popular.

Editor‘s note: "Shoebox", a codeword, is one of several used within Sun for the various mechanical packages for computer systems and or peripherals. Shoebox was announced with the Sun-3 as the external package for tape and disk drives.

Pizza box came into wide usage to describe the low profile computer housing introduced with the SPARCstation 1.

Lunchbox announced with the SPARCstation 1 was the enclosure for a single desktop SCSI storage device.

Dinnerbox announced simultaneously was a taller enclosure for multiple desktop SCSI storage devices.

[00:44] Andy: I used a diskless workstation myself at work, for many years. The hard thing was always booting, because you had to have a file server there where you could boot from, and there was kind of a hard mapping to that. Second, the virtual memory swapping over the network wasn't the greatest idea, let's just say. By the time we had the shared Ethernet with 10 megabit, and it was a hundred people in the network, it kind of slowed down.

So again, we wanted to run power applications on the local machine that involved large memory, memory swapping, and a lot of I/O, ultimately all wanted the local disk drive to get predictable performance, and that became the power workstation for like 3D CAD or even electrical CAD applications.

Whereas if you just use the workstation for, say, email, which is what I mostly did, you didn't need any of this. It worked just fine in the diskless mode. But Sun, in fact, had these multiple use cases for the products, and the demand for disk drives was very clear, starting with the Sun-2, as was mentioned earlier, and then the next version of that allowed the local disk attachment

The Sun-2/50, I was surprised to learn, had had that SCSI board.

[00:45] TomL: One of you had the picture of the memory expansion board, with the 6U VME board riding on top of that.

Editor‘s note: This Sun-2 expansion board has mounted on it as a daughter board, Sun's second SCSI host bus adapter, the "Sun-2 SCSI Host Adapter," a 6U form factor with a VME interface. It is a clone of Sun's first SCSI HBA, the "Sun-2 Multibus SCSI Host Adapter," part number 501-1006 which was designed by Mitch and comprised mainly glue logic with a DMA interface. It is not clear who designed this board, some suspect Andy because of his skill at melding together disparate circuitry. Sun's third SCSI HBA, "Sun-3 SCSI Host Adapter," part number 501-1236, was designed by Serdar Ergene as a plug replacement for this second version using an NCR 5380 chip which allowed implementation of SCSI bus arbitration (disconnect/reconnect) and replaced about 20 glue IC's saving about 4 square inches of board area.

[00:46] Rich: That wasn't available at introduction. A year later, once we had the shoebox for the Sun-3, we figured out that we could just add it to the Sun-2, and it sold a lot of them.

Andy: And to be clear, there was two versions of the Sun-2. There was the desktop one that was a single board and then there was a deskside or Multibus-based one that had the expandability.

The Sun-1 had, if I remember correctly, the five or six slots of Multibus sitting right on the desktop box underneath the monitor. There was a CPU card, a memory card, an Ethernet card, and then an optional disk controller card, all in the same box.

On the single board Sun-2, we lost the other interfaces. The Ethernet was bundled, but there was no disk interface. There was a desk side version that had more expandability, and then we kept the VME bus into the Sun-3 environment, which was a better interface than a Multibus. It had full DMA, and so on and so on, so it was a reasonable structure to build server type appliances, or power workstations, that needed a lot of I/O.

[00:47] Mitch: And the box to rule them all became the SPARCstation 1 pizza box.

Andy: That had integrated dual SCSI disk drives. Initially it was just a hundred megabyte of drive, they were [the Quantum Q105S disk drives.] And there was one problem that if you turn them off too long, they wouldn't spin up because the oil dried up or something. So I had to go to a customer once and take them out of the box and twist them. Like you do a quick twist.

You shake them. Yes, To loosen it up and then it would work again. The customer was very impressed by that, but obviously that wasn't supposed to happen either. But everybody had a disk drive at that point.

This was a 10 MIPS class machine, 10 times faster than the original Sun-1 or Sun-2s, and it really needed the performance that went with that. And, even with big memory, there was a lot more virtual memory swapping and I/O. Ever since, I think disk was pretty much bundled with almost any offering.

This concept turned into the Sun Ray machine, which was really just a virtual terminal, without an underlying operating system environment, that would allow you to run local applications. That would dial into servers, essentially, that ran the apps on a remote server. That worked surprisingly well.

[00:48] TomL: Rich mentioned NFS. NFS shipped in 1985, But prior to that, we had ND, Network Disk. So instead of file sharing, it was strictly block sharing.

Yes, and you could boot from ND.

There was a boot from ND. You can sort of think of that as a precursor to Fibre Channel in terms of block network protocol, but it was very, very simple, and horribly, horribly slow when you had too many people on the Ethernet.

[00:49] Mitch: With regard to the pizza box, I want to acknowledge the mechanical engineer that designed it. Her name was Ginger Orr and it was just a beautiful design. It was so elegant. The disk drives were just adjacent to the CPU board, and the ribbon cable was about two inches long. Everything was just wonderfully laid out in that box.

Andy: Yes, and that was one of the highest running products we had at the time, certainly. It was easy to scale and all that. Also that was when customers switched over to the SPARC architecture from previously Motorola or Intel, because the other chips were three times slower at the same price point, so there was no reason to use the older chips.

Mitch: That product anticipated blade servers, because people would just get pizza boxes and stack them.

[00:50] Andy: That's a good point. They fit perfectly into a 19 inch rack because they're 16 inches wide. For server farms people just racked and stacked them, because it was the easiest way to put capacity on a given data center.

TomL: There's famous photos from places like Lucasfilm with their rendering farms full of Suns.

Andy: Yes. It turns out, on Toy Story 1, they were running out of time or budget to finish it in time for the release. We loaned them a few hundred more machines so they could finish the rendering in time.

I've actually got a credit at the end of Toy Story 1 that acknowledged the support of Sun Microsystems with the help of the movie, and they became a very good customer afterwards.

Rich: Well, that was a result of SGI, this new company doing Jurassic Park, and doing the render farm for that, and then Raj Parekh saying, we want to do the next one at Sun. It was a bigger format. The files were four times as big. The render farm was X times what it was for SGI. But doggone it, we got Toy Story.

[00:51] TomL: Interestingly, Lucasfilm was very active with the Sun workstation, even before the company was formed. They were working with Stanford for a while.

There was something called Lucasfilm UNIX, where you could call up Lucasfilm and get a copy of UNIX.

Andy: The original Pixar group, which was at Lucasfilm, was actually maybe the first customer of any Sun product in 1982, because they were so eager to get their hands on it to start developing software suitable for rendering. This was way ahead of its time.

Editor‘s note: This log sheet shows Sun's initial shipments of eight of its first units to Lucasfilm.

Sun began shipping with serial number fifteen because Scott McNealy thought no one would take a unit numbered one and Bill Joy wanted to avoid number thirteen. "Laura" is likely Laura Tong, employee #10. The image was taken by Rich from an exhibit at Sun's September 2019 reunion.

Andy: They had a guy called John Seamons there, who was a friend of mine, and he was very eager to do their version of UNIX, to adapt it to this rendering problem.

Later when Pixar was spun out from the Lucasfilm movie company, because I guess they decided they didn't need to own the rendering technology, and Steve Jobs acquired Pixar, and they became very successful making these computer- aided movies, that was when we re-engaged with them to help them with the render farm.

We were building custom hardware, but that chip didn't pan out quite as they imagined. It was just too complicated.

[00:52] Rich: Another aspect of this that should be mentioned was backup being a part of the Sun architecture from the very beginning. So if you look at the early systems, you had half inch tape - I think you could have the whole distribution probably on one reel. You use that for loading up your workstation, you'd use it for backup, and you'd use it for media interchange type purposes. But the quarter inch cartridge tape was introduced in the Sun-1 generation, we found out by digging back through, and that was a 20 megabyte QIC-11 device, it wasn't SCSI.

It took two cartridge tapes for the UNIX distribution. But there was always a backup solution, and this became important for SCSI because you started out with a tape card and a disk card, and then, with SCSI, you had one cable that connected all of this. So we evolved the cartridge tape, starting with an enclosure that had an 8 inch disk drive alongside a quarter inch cartridge tape called the FAT box, the Fujitsu Archive Tape box that Tom Lyon disliked.

And then the tape device went into the first deskside unit. So Mitch's board powered the first deskside unit. He talked to the disk, and then we had the cartridge tape, and then went on from there.

But there was always a backup device, and then eventually tons of different technologies. We had the QIC devices, we had the DAT devices, we had the DLT, we had the eight millimeter Exabytes and it just went on and on. So the tape was always a part of this, and then eventually we'll get to the CD-ROM.

But SCSI did all of this. One connector.

[00:54] Andy: And the reason that tapes were so important was that the disk drives were failing all the time, so you better back up your data.

TomL: The spinning rust, right?

TomG: Archive was the first embedded SCSI tape drive, I think, that Sun introduced. Prior to that, it was proprietary, QIC, or other types of tape interfaces. That was late 80s.

Andy: If I can add one thing, it's an interesting difference to the personal computer environment, where nobody essentially had a tape.

They always used floppy. But floppy was, I forgot, was it 1.4 megabytes or 700 kilobytes? It was so tiny, and it just didn't make any sense. Even at one point we put a floppy disk, I think, in the SPARCstation 1- it was a mistake. There was never ever any useful use for floppies in a UNIX kind of environment, given the file sizes and the amount of data people were dealing with, whereas on the PC, it was the standard for many, many more years.

[00:55] Rich: We had 386-based products for a generation and a half, and there was an idea of interchange between the UNIX and the DOS type of environments with floppy for that type of machine.

TomL: I still have a box here. Hold on.

Mitch: You do?

Andy: You have your personal Sun memorabilia collection there?

TomL: Oh, I've got everything. But this is the box that the software distribution came in for the Sun386i.

Andy: How many of disks was it?

Editor‘s note: [The software required about 25 floppy disks.]

Andy: That many? Oh my god.

TomL: Lots of floppies.

This was clearly a bad idea.

But it's a nice box.

TomG: Any recollections about Exabyte's tape drive being introduced? It was, I think, at 2.3 gigabytes, a breakthrough in capacity.

[00:56] Andy: Yes, it actually was. And it was a standard for quite some time because of its capacity point.

TomL: But one thing I want to mention is disk drives standardized pretty rapidly in terms of behavior. But tape drives all had their weird little subtle things. My brother Bob went on to found Legato Systems, and their whole business was backup, and he jokingly said our core competency is tape drivers, because every kind of tape had different subtle things going on.

Mitch: I think the real revolution in distribution was CD-ROM.

Andy: Yes, and we added CD-ROM distribution by [1990]. That meant the whole UNIX would fit on one CD-ROM, even though even that pretty soon almost ran out. And then, the Blu-Ray, of course, never really made it as a standard in the future.

But CD-ROMs were quite popular in the mid-nineties, till I would say early 2000.

TomL: Oh, we had the add on CD-ROM much earlier than that.

Andy: Oh, that's true, too, because it was SCSI, of course. Yes, it was SCSI.

TomL: But it didn't become kind of de facto until the 90s.

[00:57] Rich: We were waiting for standardization of formats. There were industry consortiums trying to get from the music formats into a data format, and that took a while. In the meantime, I think it was being used internally. It was a while before Sun had a product that we would sell externally. Tom was reminding me that some internal adventures with having early formats to be used.

TomL: We specified a 512 byte block size for CD-ROMs, because that's what everyone used on disk, and we could use the same file system if we wanted. But the entire rest of the industry went with 2k block size, and so you couldn't really interchange the drives for a long time.

Mitch: I remember the firmware had to support both.

Andy: Especially on booting, yes.

TomG: In the late 80s you came out with your only IPI product, which seemed, from my perspective as an observer, to be an interesting choice rather late. Any recollections about that product?

[00:58] Andy: I was involved in it, and I think it was driven on the server side as an effort to have a more reliable disk drive behind it, but this has nothing to do with the workstation business.

TomL: I believe also they had the server mentality of trying to offload everything from the CPU, and so there was a lot more intelligence on the controller board, which in my experience just slowed things down a lot, but that was the prevailing attitude for servers.

[00:59] Rich: I can speak to this one since our group designed the controller. From early days of Sun, and looking through the Stanford archives, even Andy had notes about providing a Sun designed SMD controller, that would be lower cost and would be more CPU centric. So the idea of designing a controller had been around for quite a while.

We put together a design group in probably 85, 86, got some people from Systems Industries. At that time, on the roadmap there, IPI had been kicking around the ANSI committee. It came out of an environment where people wanted an idea to replace the IBM- centric channel and have something that was multi-vendor, open standard. So you had people like Gould and Honeywell and Burroughs. And STK, the tape guys, were really big on this. They wanted something that would have this channel interface, deal with blocks instead of cylinders, all the rest of that.

So that was on the roadmap of being after SMD.

The practical advantages beyond the standards were smaller. You did have one cable instead of all these different cables. You had a more robust connector. You could address a lot more devices. The fiber part of it wasn't visualized back then, but [IPI] was the next thing on the roadmap.

[01:00] Andy: IPI was pushed by IBM, Control Data, Unisys, the mainframe guys, and it was perceived to be a robust mainframe class technology, and thus more reliable. So the marketing push was we got to compete in the high-end server business. We got to have equivalent storage, disk storage, reliability to the mainframe guys.

But in the end, IPI had a fairly short life until Fibre Channel took over.

[01:00] Rich: What it ended up doing, we offered it on the highest end server, the 4/390 and 490. The IPI gave you a 3 megabyte a second, but you also could get a dual head version, a 6 megabyte a second, where the two heads were reading in parallel. So you could get all this throughput. But I think we only offered it for 2 or 3 years.

The real benefit of that was we had a design team now. Dave Banks was the key engineer on this, and we had this group from Systems Industries. They started focusing on Fibre Channel, and Sun really, really drove that technology hard. That ended up being a big winner for the second decade of what we did.

[01:01] Andy: Absolutely. We were an early adopter of Fibre Channel, it resonated with customers, it was easy from a cabling standpoint, very expandable, and it was rock solid, for all these years.

TomG: Any recollections about the transition from JBOD to RAID?

Andy: Well, RAID, this is a funny story because it was obvious that, with disk drives being as unreliable as they are, you really wanted to do the RAID parity approach to recover your data if there was a failed disk drive. On the storage side, this turned into a separate industry of people like, I forgot the first company doing this, but LSI Logic acquired them, that built these RAID arrays, and they had some RAID implementation, and some ASIC chip that would hide this function behind the Fibre Channel protocol, in such a way that your overall storage was reliable, even though an individual disk drive may have failed.

Sun didn't do its own RAID version of that, as far as I remember. This is probably something we missed doing because there was an industry product available, but it was a high margin kind of market, to make these higher end arrays, what we really required in a server environment.

I actually left Sun in 95 to start a networking company, so I don't know what happened afterwards, but in any of the high-end server class machines that Sun was very successful with, a RAIDed storage environment was a given.

[01:02] Rich: So more of the RAID story. There was a close connection between Sun and both Stanford and Berkeley. A lot of the hardware and business people came from Stanford. Bill Joy attracted a brilliant group of UNIX people from Berkeley. Berkeley was a big customer, the labs were a big customer, so there's a lot of interchange.

Part of the fun of working at Sun is we had access to these professors including Dave Patterson. Dave would come over to Sun on a regular basis in the mid-80s to talk about what would become the SPARC RISC processor[.]{.underline} While he was there, I would bring him over into the cave where the storage guys were, and we would talk about RAID. He had the Berkeley RAID group. They had RAID retreats. We participated in that.

And so we were well up to what Berkeley was doing with RAID, which they actually borrowed from another company back in the past. We followed that. We looked at products from other companies. We'd had some internal efforts, but it was always hard to match a hardware schedule with a platform schedule. You had to have something that was mature and available and ready to go into volume. Sun was a bigger company, and so it turned out to be more expeditious for us to OEM RAID products.

We worked with a group closely that started out as NCR, then became Symbios, eventually became LSI Logic. We went through the process of having RAID controller technology come from a third party, and then marrying it with disk trays full of disks, as many disks as we can cram in, and built up our systems in that way. There was always a debate whether you should have a controller in front of your storage, or whether you wanted to run with a product like Veritas, or other ones, that did software RAID. There were actually two advantages. One was for reliability point of view; you could have a failure and be robust. The other is, if you wanted bandwidth, you could gang these things together and stripe them, and get all the bandwidth you wanted. So customers liked it.

We worked as fast as we could through our partners to do this.

Then you got to Fibre Channel. For a long time, we had both JBOD versions, first with Fibre Channel loops, and then eventually you put a controller in front of it. There was always a debate, whether you had a controller, a piece of hardware, between the compute resource and all of these disks.

So we did both.

[01:05] TomL: The reason that debate goes on forever is based on who's implementing it. If you're a third party vendor, you don't want to be all over the guts inside the Sun system, and vice versa.

But I wanted to mention, at a business level, Sun missed the emergence of adjacent businesses. We missed the emergence of a storage business. We missed the emergence of a networking business. At one point, Sun was ranked number three in the router business.

Nobody knew.

It was hard for Sun to deal with these features that turned into businesses.

[01:06] Mitch: Yes, missing the Network Attached Storage. Wayne Rosing came into my office one time, talking to me and Peter Costello about his idea for a disk box with a processor that you hang on the network. Peter and I worked on it for a while, and of course, eventually that became a huge industry.

But that was something that, if we had decided to pursue that, we could have been in on the ground floor, but we may have actually been in the basement before there was a ground floor.

TomL: We probably would have been too early, and failed.

Mitch: The same thing happened with X terminals, because I prototyped a NeWs terminal and showed it at the same conference where the X terminals were being rolled out.

TomL: Rich mentioned Veritas. They were the clear leaders in terms of file systems, and that was a huge thorn in Sun's side, because you had to have Veritas in on every account. That lasted well more than a decade, I think, until Sun finally had ZFS.

[01:07] Rich: Also from a business standpoint, it was interesting over time to be aware of these different combinations. We had a very, very strong operations group and procurement group, and they would come with these things. One of the early ones was, they said, CDC wants to sell their business, I think by then they were Imprimis, and did Sun want to buy it?

I basically said, "No, we'd be crazy to do that.", was my particular input. Seagate picked that up.

But at various times, I had heard, Andy could validate, there were debates on whether Sun should buy Cisco? And missed that opportunity.

Andy: No, no, no, that was not on the table.

It was more the opposite. We didn't understand why Cisco was valued as they were. We're building a box that Sun actually had, which was a router, it's just we didn't market it as a router. Berkeley UNIX included the full routing features, but Cisco made it a separate category, and added more protocol support.

[01:08] TomL: Suddenly they became rich and famous as a network routing company.

Cisco shipped their first router in 1986, I believe.

Andy: Yes, they were using the Sun-1 Multibus card,

TomL: Yes, the Sun-1 card,

Andy: which was way obsolete by then. They took a license from our previous company to get to build these cards.

TomG: That's interesting. To me, it's the same story with Auspex, right? Auspex made a file server system, but Sun was making NFS servers all along. It's just Auspex figured out how to optimize it.

Andy: I would say NetApp did a better job on the file system level. That advantage is with them till today, surprisingly. But Sun could have been in that business if it had focused on delivering a much more reliable file system earlier.

At the time, there wasn't the priority. It was viewed that the UNIX file system, the Berkeley File System, was good enough. Arguably it was, but not as a reliable file server.

[01:09] TomL: Part of the problem was the AT&T agreement where all the operating system software was slowed down for five years to learn all this stuff.

Andy: That was the most unfortunate agreement Sun ever got into.

Rich: You also had whether Sun should buy Apple, and later on whether Apple should buy Sun.

Andy: No, it was never the other way around. There was a meeting, but luckily that didn't happen. Otherwise, we would not have the iPhone today. So I'm glad that didn't happen.

TomL: That would have been a huge culture clash.

Mitch: I just want to go on record saying that SunOS 4.0.3c was the greatest operating system ever.

Andy: I'm with you. We second all of that.

TomG: Have we missed any other storage stories that might be of interest?

[01:10] Andy: In the end, we always tried to meet the customer's requirements, either it was local storage, or scalable storage, or backup, with the best technology available at the time, and because we were early on having a microprocessor as a subsystem that was at the scale of a traditional minicomputer mainframe.

We really had to mimic what the mainframes and minicomputers were doing to have the same solutions. So yes, we were at the bleeding edge of adopting these new interfaces in a low cost environment, but customers appreciated it, and the reliability improved over time, and it got better and better and we made it work.

It was a proud history.

The PC people didn't have to go through this because all they had was floppy disks and some miniature ATA disk drive, right? But in the, in the higher end world, you know, that wouldn't have gone anywhere.

[01:11] Mitch: I think that Sun's real talent was outgrowth of Andy's ability to stuff as much as possible in an envelope until it was bulging and almost breaking, but not quite breaking. Other companies would fail because they would break the envelope, or not stuff enough in it. But Andy would go very, very fast, come up with these brilliantly elegant designs that push things just as hard as you could possibly push them without breaking them.

I felt like it was my job for a couple of years to find the one bug in Andy's design before we could ship it and iterate on that.

TomL: Well, you were lucky if it was before you could ship it.

Andy: Yes, and there were times when, I think, Bill Joy was saying that we were driving a car with not all the four wheels on the ground. That is to say one of the wheels was in the air.

That was true. But in the end, they did work. Yes, there was all kinds of birthing pains, but the long lasting value of the Berkeley operating system, and ultimately the fact that software could be fixed to, to fix bugs. People would trust us to deliver solutions that actually were even better than last year, was ingrained in the way we interacted with customers. So yes, in the end it did work and yes, there was problems, but that's not unexpected when you're the first use of a new disk interface.

[01:12] Rich: I have a couple of war stories that I could share, but one of them that I think convinced me to join the company is: Sun had nearly failed, due to problems with grayscale monitors that were arcing and failing, just before I joined the company in 1984. These monitors -- this is my understanding -- they were the highest resolution that you could get, they were running at high voltages, and they would blackout at customers. The Sun solution, as it was told to me, was they had a truck that was loaded with monitors and it would drive around to customers and replace them as they were failing.

Andy: It was pretty bad, but it turns out that the root cause was an ESD discharge from the high voltage that had built up in the monitor itself, that dribbled all the way back into the logic, into the driver of the video signal to the board, and zapped out the driver on the board. It was just a stupid design mistake on behalf of the monitor vendors. For whatever reason, we didn't catch it early on. By the time they were shipping production, every other monitor just broke down after a certain amount of time.

It was definitely the worst problem Sun had at that point. All it took was some Schottky diode, or whatever, to protect that circuit, right? That it wouldn't ripple down the wire to the workstation to zap that workstation. But it took us a while to find it and people were in fact worried that we may be not surviving this.

[01:13] Mitch: The video circuit that that monitor had a 74F74 chip that was running at... I mean, it was at the hairy edge of the timing. It was a little bit past the hairy edge of the timing.

Andy: Yes, it was running at typical data sheet value, but not at worst case value, I know because I designed the circuit. Later they changed it back to an ECL circuit, but that was actually unnecessary.

The TTL worked just fine. The real issue was this ESD zapping, and TTL wasn't designed for getting a [zap]. I'm sorry.

[01:14] Rich: The thing that impressed me though was that they didn't lose any customers, that they were very close to the customers. It was a tech community, and you kind of went from the high performance guys using a workstation, and then the company evolved from there. So it was actually a selling point for me.

Otherwise, I was worried about these crazy guys like Bill Joy and Andy. All the founders were [then] 30 years old.

Andy: That wasn't the issue. The thing was, we offered a price point that was between one fifth to one tenth of the equivalent VAX machine, then there was a desktop product instead of a full rack. It was just so much better than what they were buying otherwise in the minicomputer world, that ran the same Berkeley system. It was the same software environment, except at a much lower price point. It was an immediate sales proposition. Very early on, the Sun-1s couldn't do virtual memory because Motorola had missed out on that instruction that would allow you to fork the ongoing instruction stream, but people trusted us telling them, we will just upgrade them to the next chip, and they bought the Sun-1 anyway, ready for the upgrade.

To me, that was an eye-opening situation, because they really believed we would deliver all this, for a startup company that had barely got off the ground. The initial revenue ramp was just unbelievable, because there was no other competitive competing product at that price point in the market.

So all the challenges we had as a company, customers ultimately accepted that it was a much lower price point, and we were fixing them as we went along, and they kept buying more.

[01:15] TomL: Nothing like revenue to hide your sins.

Andy: Well, it was more like they wanted the open environment. There was Apollo, but that was a closed system. It was a completely proprietary operating system, completely proprietary network. They had two Motorola chips on the board instead of one, a huge board with thousands of chips. It just wasn't a good implementation.

Yes, some people bought that, but in the end, I don't think they were happy.

[01:16] Mitch: Some customers managed to apply mainframe disciplines to networks of Suns.

For example, when we were doing that quality team thing, EDS told us about their processes. They had a bunch of Sun workstations, one on everybody's desk. Every night, at midnight, they wiped the operating system and reloaded to make sure that nobody had, polluted it with any kind of custom drivers and stuff, so you pretty much had to keep all of your data on your own disk partition, not in the operating system partition.

Andy: Those were the old days. I remember, in the 90s, some customer showed me a machine that was up and running for like six or seven years without ever going down. They were really impressed by this, and they said, well, this is what they like about Sun.

So we turned into a quite reliable company, by the time it was the 1990s.

TomL: The longest I saw was, perhaps 10 years ago, somebody showed an uptime of 18 years on a Sun.

Andy: That's unbelievable.

Rich: Yes, I think back then, too, there were some differentiators.

So Sun was known as the open systems company, and they used that to contrast with Apollo and all these other things. We were always built on standards and volume. We drove some of the standards committees, and then we shared with others. The idea was you just had to keep running, because you were telling people what you were doing, and they could interconnect.

We were always big on performance and scale, and built on commodity parts. We had lots of sources for things, so we had to make all kinds of stuff work.

The HPC community and, and these scientific communities, they would attach all kinds of strange and wonderful things to Sun workstations. That sometimes got pretty crazy, but they could build from what we had.

And so you just had to run fast, and we did, and you had to be open.

The renaissance later on is all around being "the dot in dot com". That was probably the highlight, when we took that as the mantra.

[01:18] Andy: Yes. By the time the Internet took off, Sun was the most robust UNIX Internet server product on the market. There was very rapid growth starting in 94, 95.

But going back to being the open company, one other benefit of this was that all the other startups in this certain field would call us up, and want to offer us their products, because in the IBM world, or Control Data world, they were all locked into their own supply chain, whereas we were actually open to new suppliers.

So we interacted with countless startups over the years that had some interesting new technologies. Some of them succeeded, some of them failed, but this is how we actually got access to the latest and greatest in whatever storage there was, over time.

[01:18] TomG: That was a great sum up by Andy and Rich. Any other closing remarks?

[01:19] Mitch: I remember a pretty good story that's kind of peripherally related to storage.

My first child was about to be born. She eventually got born. She's now 37 and works for Apple as an AI researcher. She was almost due, and we were about to roll out one of the Sun-3 machines, I believe. They couldn't ship because they were doing burn-in testing in the factory, and the floating point diagnostic kept failing.

The floating point hardware group had just checked everything. They couldn't find anything wrong with this floating point unit. They called me in because it was a weird problem, and that was my forte, the weird problems. I spent days working on this, and meanwhile I said, you know, if my wife goes into labor, I have to leave.

And so as I heard, like, the exec staff was, like, praying. For the, the child to be delayed. Eventually it turned out that the floating point unit had nothing at all to do with it. The problem was that there was a bug in Berkeley UNIX that had been there forever, in which, you know, if you had to page in a bit of an executable program from the disk from a section of the disk that had to be addressed with an indirect block, there was an uninitialized variable in the VM code that caused it to fetch the wrong block.

I found that one day before my daughter was born.

[01:20] TomG: Lucky.

Rich: I think it would be good if we talk a little bit about Sun Culture because that was one of the things that was unique. It was fun. It was attractive. The company was founded by four [27] year olds. I was [four] years older than Andy.

So I was, I was a young guy too. And you know, we were the open systems company. We had to run faster, but we had a lot of fun. And, and there's many different things to celebrate there.

Andy: Right. And people just jumped in and fixed it, you know? So it was, it was a definitely the can do attitude.

TomL: When I joined the company, it was after almost four years with Amdahl.

So I think I had had a job longer than anyone else.

[01:21] Rich: I'll just go on this a little bit to trigger some memories, but you know, we would have weekly beer busts and even after we were public, we still had the weekly beer busts and Scott would tell us the big deals that were going down. And so we were very connected to the company all the way through.

We had legendary April Fools stunts ...

[01:21] Andy: Oh, my car in the office. Yes. There was a whole, every year it was different. Yes. I didn't even know it was happening. Like, it didn't cross my mind. This could be done.

TomL: Well, we if I recall, we got you to give us Bill Joy's Ferrari's keys.

Andy: Yes, there was one, but on, on, when they took my car, the car wouldn't start in the parking lot and they offered me a ride home. And I forgot it was the night of April's Fool's Day. The next morning the car was in the office.

[01:22] Mitch: That was a Porsche, wasn't it?

Andy: Yes, they had to call an electrician in the middle of the night because they thought it would fit into the office, but then they had to take out another wall and there was an electrical conduit there.

And somebody qualified had to, you know, redo that one. So it was quite a construction job in the middle of the night.

Mitch: It was a car in office, car in pond, office on pond, golf course in office, giant arrowhead in the building

Rich: up on the fifth floor of the Ford building.

TomL: Yes. I'm proud to have worked on a bunch of those. After a golf course in office, I retired because that was backbreaking work. [laughter]

Rich: Well, and we've had some great reunions since, so we could relive some of this. Tom Gardner now has a copy of the Sun-10 year yearbook that, that celebrated that. I used to know most of the badge numbers of the first 50, and these other three folks are in that group. But there was a lot of tradition.

We just had a lot of fun. We moved really fast. We were open about what we were doing. We shared. We did things in in in volume. Lots of kids were born. Lots of stuff happened. There's a very strong operations team that made this, made this work.

And we also had these transplanted cultures where they're, early on, there were the Four Phase people. There were the HP people. Later on there were the DG people. So we would have these cultural transplants, but it all became Sun. And I give, I give Andy and Scott a lot of credit for the culture, Bill Joy and the, and the software area. There was a very strong and durable culture that made it a fun place to work.

Lots of innovation lots of contact with the customers, a lot of fun.

[01:23] TomG: Okay, anybody else have anything they'd like to,

[01:24] Mitch: I just remember being completely overwhelmed by Bill and Andy. I would, I would be in Andy's office and Bill and Andy were like, talking about some idea that I was supposed to implement and they were on the same wavelength and they would finish each other's sentences.

And you know, Andy would say "What about ...". In, like one word, Bill would say, yeah, yeah, yeah. And then we basically, they would leapfrog each other. And I'm just sitting there trying to keep up because, you know, they, they actually knew exactly what each other was thinking about.

It was drinking from the fire hose.

[01:24] Andy: Well, we were, we were living at the same house at that point. So it was ongoing conversation, yes.

TomG: I have a closing question for Andy. Were you on the airplane flight back from the famous trip to Boston, where you camped out at the Computervision.

Andy: No, I was, I was not there, not on that mission.

TomG: Oh, because I was on that plane. I sat next to Scott McNealy. I still have his business card someplace when he was the Vice President of Manufacturing at the time. I was just wondering if you'd been on that plane too.

[01:25] Andy: No, no, no, it was more that deal was going to go to Apollo.

Right. But. We ultimately gave Computervision a deal that Apollo couldn't match, which is we gave them a license to manufacture their own product, and they had their own manufacturing operations, which they didn't really want to shut down. So they got a free license to the Sun-2 generation - us knowing full well that by the time the Sun-3 would run, they would buy the next product from us.

But it was a very fruitful relationship for both parties, I would say, and it puts Sun on the map on the CAD, 3D CAD for MCAD.

[01:25] TomG: I think this is probably a good time to end this meeting. I really appreciate the four of you taking your time to share your recollections. The next step will be, this will be transcribed, you'll get a chance to edit it.

And ultimately, it'll be published either with the IEEE or the Computer History Museum or both. Thank you guys. I appreciate it. It's been fun. I've learned a lot and I hope you guys have enjoyed it, too.

[01:26] Andy: It was fun to be here.

TomL: Yes. Good to see you guys.

Rich: Scott McNealy's motto was kick butt and have fun.

AND THEY DID!!

Editor‘s note: This interview has been edited for accuracy and lightly edited for readability. The participants believe the transcript to be accurate as of the date of the last edit.

Filler word such as "uh" have been deleted from the transcript, video and audio; other minor changes for readability, such as "Yeah" to "Yes" have been changed in the transcript but may remain in the audio.

Changes in meaning and small additions are indicated by brackets [ ... ] in the transcript which may or may not be reflected in the audio.

End of transcript