[patrck]

Though, if your bias is towards action, how do you avoid stepping on toes?

These discussions seem like MBA brain-teasers, ie. there can't be any hard and fast rules, so each case needs to be individually worked out.

There's probably a sub-reddit for this.

[chasil]

True to form, Cutler had a break with DEC, and they gave him a carte-blanche VAX "skunkworks" with Prism/Mica.

DEC eventually shut this down, which prompted his departure for Microsoft. This is unfortunate for DEC, as they eventually poured the company into their Alpha RISC processor, which did not live as long as DEC hoped. Prism might have been a superior design.

At this time, Microsoft was maintaining a UNIX kernel in their Xenix product, so they knew a good kernel engineer when they met one. Microsoft was the leading UNIX vendor in the early 80's.

Cutler famously disparaged the UNIX kernel (his notable saying was "Get a byte, get a byte, get a byte byte byte" to the tune of the finale of Rossini's William Tell Overture).

Microsoft dumped their Xenix onto SCO about this time.

What is more interesting to me was Cutler's involvement with Azure. He must have had some sway over CBL-Mariner, Microsoft's RPM-based Linux distribution.

Much of Cutler's earlier work is documented in the "Showstoppers" book:

https://www.amazon.com/Show-Stopper-Breakneck-Generation-Mic...

The book doesn't really delve into the Xenix decisions, if I remember correctly.

Without Cutler, Microsoft would likely have ended up on a BSD kernel, as Apple did.

[voidfunc]

> What is more interesting to me was Cutler's involvement with Azure. He must have had some sway over CBL-Mariner, Microsoft's RPM-based Linux distribution.

He was involved with Red Dog (the modified Windows host that powers Azure).

He's not involved with CBL-Mariner team at all to my awareness. Mariner is mostly about solving a supply-chain problem at Microsoft... we have a ton of internal teams all using different flavors of Linux and packages have historically come from all over the place. With CBL-Mariner we are basically trying to unify on that and own the package build and distribution portion as well. There isn't much reason for a kernel designer to be involved in that as its a well-understood problem (and entirely different domain) and we already have internal upstream Linux kernel contributors (which is how produce -azure supported kernels).

[bluejekyll]

Apple didn’t end up on a BSD kernel. They started on Mach (from NeXT) and then made it more performant with XNU by not being so pedantic about microkernels.

BSD is just a supported kernel ABI.

Edit: I just found these docs, so I suppose it’s a bit more complicated that I’m stating, I.e. there are portions of the FreeBSD kernel directly in macOS https://developer.apple.com/library/archive/documentation/Da...

[chasil]

I only know what I've read.

"XNU was a hybrid kernel derived from version 2.5 of the Mach kernel developed at Carnegie Mellon University, which incorporated the bulk of the 4.3BSD kernel modified to run atop Mach primitives..."

https://en.m.wikipedia.org/wiki/XNU

[jbverschoor]

4.3BSD is not FreeBSD

[bluejekyll]

This is from the link I provided: “The BSD portion of the OS X kernel is derived primarily from FreeBSD, a version of 4.4BSD that offers advanced networking, performance, security, and compatibility features. BSD variants in general are derived (sometimes indirectly) from 4.4BSD-Lite Release 2 from the Computer Systems Research Group (CSRG) at the University of California at Berkeley.”

[fluidcruft]

After NeXTStep was adopted by Apple, they hired a bunch of the FreeBSD core developers and updated the BSD service and userland using FreeBSD. Apple was actually already messing around with Mach prior to that with MkLinux so there was some initial speculation that they might port to MkLinux rather than update NeXT's Mach+BSD hybrid.

[p_l]

The code updates are very limited, though. To the point that for one's own sanity it's better to assume userland is 4.3BSD unless marked otherwise (been burned by this myself in code that assumed every BSD had changes from ~1994 NetBSD)

[teh_klev]

I think you're replying to the wrong comment.

[p_l]

MacOS X essentially started by updating the NeXT core to latest OSFMK distribution, which was hybrid system (bsd server integrated into kernel space) powering the BSD alternative to SystemV - OSF/1 (most famous of them being DEC OSF/1 aka Digital Unix aka Compaq Tru64). They applied bits of FreeBSD to the bsd server code and over time improved its concurrency, but considerable portion of XNU is code that is called by bsd server but not part of bsd server (IOKit, among other things)

[formerly_proven]

> Cutler famously disparaged the UNIX kernel (his notable saying was "Get a byte, get a byte, get a byte byte byte" to the tune of the finale of Rossini's William Tell Overture).

I'm pretty sure that had to be in reference to STREAMS, because the original UNIX I/O model certainly is not byte-oriented. So basically, entirely irrelevant.

[chasil]

Maybe I should have used this one instead?

"Unix is a junk OS designed by a committee of PhDs." -Dave Cutler

[chasil]

...I just checked for Xenix in G. Pascal Zachary's "Showstopper! The Breakneck Race to Create Windows NT and the Next Generation at Microsoft."

Xenix is not in the index, which really detracts from the motivations behind the story.

[foobarian]

> Microsoft would likely have ended up on a BSD kernel

IIRC their TCP/IP stack was FreeBSD's at least for a while

[p_l]

Berkeley was paid to port TCP/IP to unix and as far as I know, part of the deal was that the code should be available to quickly port TCP/IP to more systems including non-BSD.

Thus considerable portion of Operating systems at one point or another used BSD4.3-derived network stack to detriment of network API evolution (sometimes updated with later code), some over time developing their own implementation.

[bfung]

“Bias for action” is a nice catch phrase and not bad to get people out of paralysis.

The other successful thing to add onto it, is to tell people what you’re going to do (ex, a high level 3 step plan, not more than 5), then do it. If there are objections, ask [what can be done] to mitigate the issue instead of arguing the points.

Don’t “bias for action” and do something w/o setting expectations first.

[malfist]

I believe (and I could be entirely wrong here), "bias for action" comes from Amazon's leadership principles, it describes this trade off:

>Bias for Action

>Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.

[chasil]

I have another lost interview with Dave Cutler that Microsoft took down from their website about ten years ago. I can find and post it, if there is interest.

[chasil]

(1/3)

I found this as an MHT file, edited as best I can. Maybe I should get this to archive.org?

  Date: Sat, 23 Oct 2004 09:40:05 -0700
  From: Windows Contact Us <[e-mail]>

We apologize for the delay in our response.

I have attached "The Architects: First, Get the Spec Right" an interview with Cutler and Mark Lucovsky.

Goldie, Microsoft.com Customer Support

___

The Architects: First, Get the Spec Right

Once upon a time ... there was NT OS/2.

Every month, Nadine Kano prowls the halls of Redmond to profile the real folks behind Windows 2000 development. This month: David Cutler and Mark Lucovsky, who helped guide the operating system from its infancy.

"Well, we were just about to leave," David Cutler says from behind his desk.

I'm five minutes late to my interview with Cutler and Mark Lucovsky, two of the original architects of the Microsoft Windows NT operating system.

As I wilt into the carpet, I realize Lucovsky must have mentioned to his colleague how nervous I was about approaching them. After all, who the hell am I to be talking with these guys? They are developers' developers two of the visionaries behind the operating system that began as NT OS/2 and has evolved into Windows 2000. Cutler refuses virtually all interviews with the press, but he and Lucovsky are willing to talk to me, a program manager from down the hall. They probably find my nervousness amusing.

Build it, ground up

I was a college senior when Bill Gates personally recruited Cutler, Lucovsky, and others from Digital to begin the NT OS/2 project at Microsoft. Their quest was to build, from the ground up, an advanced PC operating system, something far beyond MS-DOS. NT signified "New Technology."

One of my engineering classmates, David Treadwell, joined Microsoft to work on NT. I remember how excited he was to be a part of this obscure little development effort that none of us really understood. Remember that 1989 was before Windows 3.0. In 1989, Windows was still a nonentity.

[NegativeLatency]

> Maybe I should get this to archive.org?

Yes please

[dewey]

I just found one linked here: https://blog.codinghorror.com/showstopper/ which points to "https://www.microsoft.com/windows2000/server/evaluation/news...". Unfortunately I couldn't find a working copy in the Archive:

https://web.archive.org/web/20041101000000*/https://www.micr...

[chasil]

(3/3)

"For example, we went with a client-server design, though at first things like context-switching rates and cache misses were too high," Lucovsky recalls. "Things were slow. But we didn't let ourselves get concerned with the size of memory. Not everything can be at the top of the list. We consciously put performance lower on the list than extensibility and didn't pay close attention to memory footprint until (version) 3.5."

We talk about how the operating system evolved with each release, from memory optimizations and Power PC support in versions 3.5 and 3.51 to kernel-mode GDI and User, plus a new user interface in version 4.0. "The basic, internal architecture has not changed, except for Plug and Play," Cutler says.

"We wanted a good design from the beginning so that, ideally, people could put anything on top of the system once it was there. We focused on the underpinnings. We wanted to minimize the need to add to the base or to tear up the base, because doing those sorts of things creates a lot of bugs. If moving forward you don't have to touch the basic code except to make small tweaks, then you know you got it right."

Some things must wait

At the same time, Cutler admits, "Nothing is ever architecturally correct." Needs evolve, and it takes time to build an operating system. Although support for distributed computing and clustering were part of the original vision, features such as the Active Directory haven't come to fruition until Windows 2000. "If we tried to give customers everything with the first release, we would never have finished it," Lucovsky says.

Cutler elaborates on this philosophy. "If what we desire is to have a mature operating system, then we need to achieve revolution through evolution, through incremental improvements. Within five iterations of an operating system like Windows NT, you see a big difference."

Both Cutler and Lucovsky see taking advantage of every opportunity to increase quality as the top priority for Windows.

Reliable is cool

"I'd much rather see the most reliable and usable operating system than the most whizzy-bang operating system," Cutler says. "To increase reliability we have to make choices. For every 10 bugs we fix, we may introduce three more. But do you want to ship with 10 bugs, or do you want to ship with three?"

"Do you want one more new feature," Lucovsky concurs, "or do you want to fix more bugs?

"When the Internet was first catching on, it was OK if your browser crashed once in a while. But these days, if you go to an e-commerce site and you hit the Buy' button, things had better work. When you're dealing with a leading-edge piece of technology, you can play fast and loose with it. But as the technology matures, playing fast and loose isn't acceptable anymore. This is characteristic of the maturing process for a product like Windows. People will put up with more from the bleeding edge."

"What I think is cool," Cutler interjects, "is that the system doesn't crash, and it doesn't lose my work, and it has functionality. I could care less that the visuals are flashy if my 32-gig hard drive goes away."

Communicating quality

"And if you're a consumer," Lucovsky responds, "you want even better reliability." He concludes: "Quality is the most important vision that everyone working on this product needs to share. It isn't always easy to communicate how we're going to do this, particularly as the team gets bigger."

The growth in the number of people working on the project over the last 10 years has other downsides, Lucovsky notes. "When you have a bigger group, quality problems become especially detrimental to productivity. Say it takes 10 developers and testers to fix one bug. Whoever put that bug in there just caused 10 people to lose time. We're working to make sure our development tools keep up with the growth in our system and our team. We're streamlining the process in ways that will make a dramatic difference in the way we build the code."

"If we want to stay competitive," agrees Cutler, "we have to invest money in tools and mechanics as well as features. We need to put guidelines on paper so that people stay good at planning. Simple things like writing a good spec are basic to software engineering."

Museum quality

It all comes back to the spec.

As I leave Cutler's office, I wrap the NT/OS2 spec in my jacket and head back to my building. I have three computers with lots of whiz-bangy, new fangled things running on them, but for a few hours it's the spec that holds my fascination. As a Microsoft geek, I feel like I'm holding a piece of history. And it turns out I am. This fall, the spec I borrowed for a time will join the Information Technology collection at the Smithsonian Institution's National Museum of American History in Washington, D.C. It's another good reason to write a spec.

[NegativeLatency]

Interested!

[chasil]

I'll dig it up tomorrow.

[wging]

Any chance it also exists on web.archive.org?

[indigodaddy]

Following!

[chasil]

(2/3)

I sputter a bit as I look at the clock on Cutler's desk, smile, and take a seat.

To begin the interview, I want to set the context. What was the team's initial vision for an operating system?

"We had five or six major goals," says Cutler. He pulls a copy of Helen Custer's book Inside Windows NT from his bookshelf and flips through the pages. Portability, reliability, extensibility, compatibility, performance. I think that's right. Let me see."

He goes back to the bookshelf to retrieve a thick black binder. The label on its spine says "NT OS/2 Design Workbook." He flips through some pages.

"Here," says Cutler, casually handing me the volume. "Why don't you borrow this? As long as I get it back," he continues. "I think it's one of the only copies left."

Four inches of spec

Inside the binder, separated by a dozen neatly arranged tabs, are 4 inches of documents that make up the original specification. Dated 1989 and 1990, they bear names like Kernel Chapter, Virtual Memory, I/O Management, File System, and Subsystem Security. Page 1 of the introduction, written by Lou Perazzoli, reads: "The NT OS/2 system is a portable implementation of OS/2 developed in a high-level language. The initial release of NT OS/2 is targeted for Intel 860-based hardware, which includes both personal computers and servers..."

I try to keep my expression casual as I set the volume on the table next to me. I know these guys find reverence irritating. I hope it's not raining. How will I get the spec back to my office? Doesn't this binder belong in a museum? God, I hope it's not raining.

"Do you think you achieved these goals?" I ask.

"We certainly achieved extensibility and portability," Lucovsky says. "We tested ourselves by not doing the x86 version first. We did the RISC (Reduced Instruction Set Computing) stuff first. It would have been so easy to drop the RISC support; everyone in the company wanted to. But the only way to achieve portability is to develop for more than one platform at a time. It cost us a lot to keep portability alive, but we did, and that has made it easy for us to respond to things like Merced," he says, referring to the 64-bit chip from Intel.

No embedded semantics in the kernel

At every step, Cutler and Lucovsky explain, the team prioritized design. They knew that the code they were building had to last for years. This meant thinking ahead, understanding, for example, that hardware would evolve perhaps drastically.

"We tried to create a system that had a good, solid design, as opposed to one that would run optimally on hardware of the time," Cutler explains. "When we started, we were working on 386/20's. At the time that was a big, honking machine. Since our design had to be portable, we didn't allow people to optimize code in assembly language, which is hardware specific. This was hard for the Microsoft mentality at the time. Everyone wanted to optimize code in assembler."

The original vision kept the operating system nimble. "We didn't embed operating-system semantics into the kernel," Cutler explains. "So when we switched from OS/2 to Windows, we didn't take a major hit. If we had built OS/2 threading or signals into the kernel, we would have been in trouble. Instead we built the OS in layers and created subsystems to handle OS/2, Windows, and POSIX."

Not everything can top the list

But the original vision also required tradeoffs. The team's engineering philosophy was to focus on one major area at a time. "That's why we wrote a spec," says Lucovsky. "The way we see it, write down what you're going to do, and then execute on it. Don't stand around dreaming, telling yourself, 'Wouldn't it be nice if' We spelled out what we planned to do right there," he says, pointing to the spec sitting next to me, "and we stuck by what we said we would do.

[kinos]

Delegate the prioritization by using a template similar to this one.

> "Hey, I noticed [this thing that I think might be a problem]. Would you like me to [do a specific action that would probably fix it] or move onto something else?"