Sprite, Amoeba, Clouds

2008-02-10T19:26:00Z

Oka: /* Solutions */

==Readings==

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-01-28/ousterhout-sprite.pdf John Ousterhout et al., "The Sprite Network Operating System" (1987)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-01-28/tanenbaum-amoeba.pdf Andrew Tannenbaum et al., "The Amoeba System" (1990)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-01-28/clouds-dasgupta.pdf 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"'.

Sprite, Amoeba, Clouds

2008-02-10T19:02:38Z

Oka:

==Readings==

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-01-28/ousterhout-sprite.pdf John Ousterhout et al., "The Sprite Network Operating System" (1987)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-01-28/tanenbaum-amoeba.pdf Andrew Tannenbaum et al., "The Amoeba System" (1990)]

[http://homeostasis.scs.carleton.ca/~soma/distos/2008-01-28/clouds-dasgupta.pdf 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

FootNote (*): Ameoba dataserver knew the file and contents, but not the location of the file (directory hierarchy).

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

Soma-notes - User contributions [en]

Sprite, Amoeba, Clouds

Sprite, Amoeba, Clouds