Advanced Topics in Computer Systems


Anthony Joseph & Joe Hellerstein


Unix and Multics: OS History

Administrative Matters


Entrance exams back at break. Basic standard was 65 or above. Between 50 and 64 you have to come in for an interview. Below 50, please review undergraduate OS material again.


Office hours today: 10:30 to 12:00 for interviews


I’m away at a PC meeting for the rest of the week.


Office hours next week: TBA


OS History


Material should mostly be a review.


The UNIX Time-Sharing System – Classic system and paper: described almost entirely in 10 pages. Key idea: elegant combination of a few concepts that fit together well.


Multics – The First Seven Years – More of a classic retrospective paper (lots of lessons learned). Key idea: well-thought out grand set of goals that were mostly successfully delivered.


What is an Operating System?

        Traffic Cop


        Provides standardized services


Why use an OS?

        Fairness – central point of control

        Implement once


Who Uses OS?

        Everyday users: office applications

        CS researchers

        Programmers: edit, compile, debug cycle


        Process control

        Back room business servers


Approach to design of OS

        Top-down (Multics)

o       Clear goals drive design and primitives

        Bottom-up (UNIX)

o       Primitives define functionality

o       No predefined goals yields general purpose solution

o       Most important job of UNIX is “to provide a filesystem”



        Multics started 1965 (ran to 10/00)

o       First relational DB 6/76

        UNIX started 1969 –

o       Born when Multics was being deployed


Deployment style

        Multics: classic text book style

o       MIT Project MAC (now LCS)

         Design is key strength

o       Bell Telephone Labs (now Lucent Labs)

         Online update capabilities, robustness, scalability

o       GE/Honeywell

         Defense contractor

        Unix: two people

o       Ken Thompson, Dennis Ritchie (Bell Labs)

o       Dissatisfied with available facilities (“stealth project”)


Development cycle


o       Fall 1964 to spring 1967

o       3K page manual BEFORE code (PL/1)

o       Lessons learned: devil is in the details

         Abstraction choices

         Complex algorithm for simple functions

         Overly complex (and limiting) specifications

o       Need to evolve: design, build, evaluate, design, build, evaluate…

o       Ready for system programmers in late 1968

o       Users 1969 (five years later!)

o       $6M/year for five years (same scale as mainframe OS development of once per decade)

o       150 person-years plus 50 person-years of improvements


o       Two person years

         Built as ASM program

         Some second system effect

         Build/design mixed at same time (goal is low level: good primitives)


OS Goals

        Easy access as norm


        Dynamic, online growth of resources

        Reliable filesystem

        Security and secure selective information sharing

        Hierarchical information storage and administration

        Fair share to large and small

        Support for different programming environments and user interfaces

        Capability to evolve with technology and legacy support

        Efficient resource utilization


Easy access as norm


o       Operator console

o       Batch

        Online, time sharing as primary mode of access

o       Primary UNIX goal



        24 x 7 x 365 operation

o       Must be self-maintaining (Unix primary goal)

o       Users: universities


o       Multics users: military, governmental agencies, NSA, Ford, process controllers, …


o       Multics: 1 – 2 crashes/day early on

o       Unix: Crash every other day early on


Dynamic, online growth of resources

        Very complex

        Why provide?

o       System growth!

o       Multics:

         5 – 10 new modules/day (75% done online)

         Even applications can upgrade online

         Phone switches can do this, but not routers!

o       Enables rapid prototyping

         Can change HW/SW

         Multics: 5 – 10 times per day without effect

         Don’t try this with Windows XP


Reliable filesystem


o       Multics: Replace punch cards as backup

o       Unix: Compare treatment of metadata with user data

         Logical consistency, synchronous for metadata only


Security and secure selective information sharing


o       Protection rings: Appear in later Intel CPUs, not Unix

o       Windows NT/2K has rings

o       Achieved B2 in 8/85


o       All or nothing: super user model

        Why have multiple levels?

o       Do you trust the operator?

o       How to handle backups?


Hierarchical information storage and administration


o       Multics: multiprocessor support from start


o       Multics:

         Transparent multi-level memory model

         True memory-mapped world view

o       Unix:

         Simple 3 segment view

         Partial memory mapped model later


o       Multics/Unix: Directories instead of flat files in user volumes (e.g., VM/370)


o       Unix: Directories as special files (like indexes as relations)


Support for different programming environments and user interfaces

        Multics/Unix: Lots of languages

        Multics: Virtual environments (e.g., BASIC for class)

        Unix: Shell environments

o       Same as any program

o       Enables trivial recursion: read, evaluate (exec)

o       But, how to bootstrap?

         init process creates login process (“shell”) per channel


Capability to evolve with technology and legacy support

        35 years for Multics

o       From drum memory to VLSI

        31+ years for Unix (primary goal is evolution)


Efficient resource utilization


o       Easy to run any program (primary goal)

o       Frugal: 42 Kbytes (primary goal)

o       Old, unused PDP-7


o       Cadillac: 1  MWord = 4 MBytes

o       Custom hardware

         Paging device: 4 MWords (36 bit) = 16 MBytes in 1964!

        Compare with 1 MByte of RAM = $1 million





o       “Failed” because it was a computer utility

         Ahead of its time – no Internet for access

o       Follow on to Compatible Time Sharing System (CTSS)

         Too complicated, too costly hardware

         “Second System Effect” term coined by Fred Brooks

        System one was successful (CTSS)

        System two aims to correct all flaws from #1

        Almost always fails: too bloated, slow, etc.


o       Low cost hardware

o       University adoption

o       Simple, elegant, but slow early on

         Example: file system


UNIX Summary

System features:


Version 3 Unix: small, frugal, simple


File System:




Special files: Very powerful, why?


Removable file systems: Adapt to change!


Protection: One area of limited success


Uniform I/O model: But, no application-level semantics: problem for DBs!


File system implementation:


I-node table:


Processes and images:




The Shell: Elegant recursion