Sprite, Amoeba, Clouds: Difference between revisions

Latest revision as of 19:26, 10 February 2008

Readings

John Ousterhout et al., "The Sprite Network Operating System" (1987)

Andrew Tannenbaum et al., "The Amoeba System" (1990)

Partha Dasgupta et al., "The Clouds Distributed Operating System" (1991)

Questions to be discussed

What did the (technical) world look like when this distributed OS was designed & implemented?
What are the key design features of the OS? What are the key compromises?
To what extent is their system a "distributed operating system"?
What is the basic argument for their design choices? What evidence do they cite in their favor?
To what extent do you "believe" their design choices were right? Why?
To what extent does their design work in the context of the modern Internet? Discuss wins and limitations.
What concepts from the paper have been adopted by today's systems? What concepts should be adopted? What should be ignored?

Putting All Together

[oka's note] Sorry, I could not put it in a two column tabular format, which could have demonstrated the interaction between the columns better. You might want to consider "reading" it that way, though: For most of the entries in the lists ("problems" and "solutions"), the items in each list are usually related to one-another, in a "leap-frog way" (that is, problem item-i is addressed by solution item-i, which in turn creates/exposes problem item-(i+1), etc.)

We have discussed a number of systems that have been developed to address certain problems.

Problems

Accessing remote files (like local files)
- File Consistency
- Uniform Naming
Fault Tolerance
- hot-spots/load distribution
Performance
- Slow Kernel Switches
- kernel modularity
- kernel extensibility
- kernel robustness/security
Security
Manageability
- inaccessible resources
- dangling resources
Scalability
- high latency (in communications)
Synchronization
Legacy Support

Solutions

Distributed File Systems
- File Locks
- Metadata servers
- File versioning / conflict resolution
Dynamic prefix tables (zones of authority) [name resolution]
Redundant Execution
Caching
- Immutable files
- Process migration
micro-kernels
garbage collection
data replication
support for parallel processing
caching
multi-cast
lightweight + RPC

Quotables

'Mainframe is back. It is called "google"'.

@@ Line 16: / Line 16: @@
 # To what extent does their design work in the context of the modern Internet?  Discuss wins and limitations.
 # What concepts from the paper have been adopted by today's systems?  What concepts should be adopted?  What should be ignored?
+== Putting All Together==
+[''oka's note''] Sorry, I could not put it in a two column tabular format, which could have demonstrated the interaction between the columns better. You might want to consider "reading" it that way, though: For most of the entries in the lists ("problems" and "solutions"), the items in each list are usually related to one-another, in a "leap-frog way" (that is, problem item-i is addressed by solution item-i, which in turn creates/exposes problem item-(i+1), etc.)
+We have discussed a number of systems that have been developed to address certain problems.
+===Problems===
+* Accessing remote files (like local files)
+** File Consistency
+** Uniform Naming
+* Fault Tolerance
+** hot-spots/load distribution
+* '''Performance'''
+* - Slow Kernel Switches
+* - kernel modularity
+* - kernel extensibility
+* - kernel robustness/security
+*'''Security'''
+*'''Manageability'''
+* - inaccessible resources
+* - dangling resources
+*'''Scalability'''
+* - high latency (in communications)
+*Synchronization
+*Legacy Support
+===Solutions===
+* Distributed File Systems
+* - File Locks
+* - Metadata servers
+* - File versioning / conflict resolution
+* Dynamic prefix tables (zones of authority) [name resolution]
+* Redundant Execution
+* Caching
+* - Immutable files
+* - Process migration
+* micro-kernels
+* garbage collection
+* data replication
+* support for parallel processing
+* caching
+* multi-cast
+* lightweight + RPC
+===Quotables===
+'Mainframe is back. It is called "google"'.