Locus, V, Mach - Revision history

Rgould: Add notes for Yuri

2008-02-02T18:25:39Z

Add notes for Yuri

← Older revision		Revision as of 18:25, 2 February 2008
Line 21:		Line 21:
	# To what extent does their design work in the context of the modern Internet? Discuss wins and limitations.		# 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?		# What concepts from the paper have been adopted by today's systems? What concepts should be adopted? What should be ignored?

			==Debate about the OSes==

			Topic: Microsoft has more to learn from ______ rather than ______ or ______
			because....

			===LOCUS===
			* + error handling
			* + automatic file merging
			* - sync. hotspots
			** + fix by smart directory placement
			* + automatic backups
			* - not scalable

			===V===
			* + standard protocols
			** - less profitable, no lock-in
			* + process migration
			* - slow -> context switches
			* + distributed processes

			===MACH===
			* + microkernel -> fault tolerant
			* + user space OS extensions
			* + easy shared memory (memory obj)
			* - inefficient finding of resources (ports)
			** + use discovery service
			*** + more secure
			**** - port search
			* - slow -> context switches
			* + "real" production use

Soma at 05:06, 17 January 2008

2008-01-17T05:06:15Z

← Older revision		Revision as of 05:06, 17 January 2008
Line 11:		Line 11:

	This paper describes some key ideas behind Mach, a seminal microkernel-based operating system. The design of Mach informs later work in distributed operating systems. For more background on Mach, I suggest reading [http://en.wikipedia.org/wiki/Mach_kernel Wikipedia's article on Mach].		This paper describes some key ideas behind Mach, a seminal microkernel-based operating system. The design of Mach informs later work in distributed operating systems. For more background on Mach, I suggest reading [http://en.wikipedia.org/wiki/Mach_kernel Wikipedia's article on Mach].


	~~===Comments===~~
	~~RPC makes the simple things easy, but the most difficult aspects are still prevalent. Good to use if you are only using the common case. For example, a cluster that is isolated from the Internet.~~

	==Questions to be discussed==		==Questions to be discussed==

Soma at 05:03, 17 January 2008

2008-01-17T05:03:40Z

← Older revision		Revision as of 05:03, 17 January 2008
Line 12:		Line 12:
	This paper describes some key ideas behind Mach, a seminal microkernel-based operating system. The design of Mach informs later work in distributed operating systems. For more background on Mach, I suggest reading [http://en.wikipedia.org/wiki/Mach_kernel Wikipedia's article on Mach].		This paper describes some key ideas behind Mach, a seminal microkernel-based operating system. The design of Mach informs later work in distributed operating systems. For more background on Mach, I suggest reading [http://en.wikipedia.org/wiki/Mach_kernel Wikipedia's article on Mach].

	~~==Debate==~~
	~~Debate about the pros and cons of RPC. Topic: RPCs are the right foundation for the distributed applications (on today's Internet).~~

	~~===Pros===~~
	~~# Easy to use~~
	~~#* makes remove procedure calls look like local calls~~
	~~#* local is easy~~
	~~#* therefore remove is easy with RPC - good!~~
	~~# (Counter to first con) Use standards, problem goes away~~
	~~# Easy to debug~~
	~~# Avoids complexity of protocol design~~
	~~# RPC can be abstracted from the protocol design~~
	~~# (Counter to fourth con) Use threads for interactivity. Manage complexity by doing things pairwise.~~
	~~# (Counter to fifth con) - wrong!~~
	~~# (Counter to seventh con) - Use standards (ORBs in CORBA, etc.) for authentication~~
	~~# (Counter to eighth con) - But you specify the API~~
	~~# (Counter to ninth con) - It's the same with other methods. But RPC makes it easier to do.~~

	~~===Cons===~~
	~~# Language/implementation specific~~
	~~# (Counter to third pro) Not easy to debug. example: NullPointerException thrown on server, containing line of erroneous code running on the server.~~
	~~# Counter to fifth pro) But there is more overhead - slower~~
	~~# Synchronous - wrong model for large, distributed applications, and also bad for users~~
	~~# Limited scalability - hard to do well~~
	~~# Limited control of communication details~~
	~~# Authentication is opaque~~
	~~# Larger attack surface area~~
	~~# Poor match to listening (hard for server to communicate information back to client)~~
	~~# Backwards compatibility is difficult~~
	~~# RPC is not a "natural" interaction style - message passing is more similar to human communication~~
	~~# Too much to set up for simple applications~~
	~~# Less flexible~~

	===Comments===		===Comments===

Rgould at 20:54, 16 January 2008

2008-01-16T20:54:46Z

← Older revision		Revision as of 20:54, 16 January 2008
Line 44:		Line 44:
	# Too much to set up for simple applications		# Too much to set up for simple applications
	# Less flexible		# Less flexible

			===Comments===
			RPC makes the simple things easy, but the most difficult aspects are still prevalent. Good to use if you are only using the common case. For example, a cluster that is isolated from the Internet.

	==Questions to be discussed==		==Questions to be discussed==

Rgould at 20:48, 16 January 2008

2008-01-16T20:48:49Z

← Older revision		Revision as of 20:48, 16 January 2008
Line 25:		Line 25:
	# RPC can be abstracted from the protocol design		# RPC can be abstracted from the protocol design
	# (Counter to fourth con) Use threads for interactivity. Manage complexity by doing things pairwise.		# (Counter to fourth con) Use threads for interactivity. Manage complexity by doing things pairwise.
	#		# (Counter to fifth con) - wrong!
			# (Counter to seventh con) - Use standards (ORBs in CORBA, etc.) for authentication
			# (Counter to eighth con) - But you specify the API
			# (Counter to ninth con) - It's the same with other methods. But RPC makes it easier to do.

	===Cons===		===Cons===
Line 36:		Line 39:
	# Authentication is opaque		# Authentication is opaque
	# Larger attack surface area		# Larger attack surface area
			# Poor match to listening (hard for server to communicate information back to client)
			# Backwards compatibility is difficult
			# RPC is not a "natural" interaction style - message passing is more similar to human communication
			# Too much to set up for simple applications
			# Less flexible

	==Questions to be discussed==		==Questions to be discussed==

Rgould at 20:37, 16 January 2008

2008-01-16T20:37:24Z

← Older revision		Revision as of 20:37, 16 January 2008
Line 15:		Line 15:
	Debate about the pros and cons of RPC. Topic: RPCs are the right foundation for the distributed applications (on today's Internet).		Debate about the pros and cons of RPC. Topic: RPCs are the right foundation for the distributed applications (on today's Internet).

	==~~Pro~~==		===Pros===
	# Easy to use		# Easy to use
	#* makes remove procedure calls look like local calls		#* makes remove procedure calls look like local calls
Line 25:		Line 25:
	# RPC can be abstracted from the protocol design		# RPC can be abstracted from the protocol design
	# (Counter to fourth con) Use threads for interactivity. Manage complexity by doing things pairwise.		# (Counter to fourth con) Use threads for interactivity. Manage complexity by doing things pairwise.
			#

	==~~Con~~==		===Cons===
	# Language/implementation specific		# Language/implementation specific
	# (Counter to third pro) Not easy to debug. example: NullPointerException thrown on server, containing line of erroneous code running on the server.		# (Counter to third pro) Not easy to debug. example: NullPointerException thrown on server, containing line of erroneous code running on the server.
	# Counter to fifth pro) But there is more overhead - slower		# Counter to fifth pro) But there is more overhead - slower
	# Synchronous - wrong model for large, distributed applications, and also bad for users		# Synchronous - wrong model for large, distributed applications, and also bad for users
			# Limited scalability - hard to do well
			# Limited control of communication details
			# Authentication is opaque
			# Larger attack surface area

	==Questions to be discussed==		==Questions to be discussed==

Rgould at 20:23, 16 January 2008

2008-01-16T20:23:52Z

← Older revision		Revision as of 20:23, 16 January 2008
Line 11:		Line 11:

	This paper describes some key ideas behind Mach, a seminal microkernel-based operating system. The design of Mach informs later work in distributed operating systems. For more background on Mach, I suggest reading [http://en.wikipedia.org/wiki/Mach_kernel Wikipedia's article on Mach].		This paper describes some key ideas behind Mach, a seminal microkernel-based operating system. The design of Mach informs later work in distributed operating systems. For more background on Mach, I suggest reading [http://en.wikipedia.org/wiki/Mach_kernel Wikipedia's article on Mach].

			==Debate==
			Debate about the pros and cons of RPC. Topic: RPCs are the right foundation for the distributed applications (on today's Internet).

			==Pro==
			# Easy to use
			#* makes remove procedure calls look like local calls
			#* local is easy
			#* therefore remove is easy with RPC - good!
			# (Counter to first con) Use standards, problem goes away
			# Easy to debug
			# Avoids complexity of protocol design
			# RPC can be abstracted from the protocol design
			# (Counter to fourth con) Use threads for interactivity. Manage complexity by doing things pairwise.

			==Con==
			# Language/implementation specific
			# (Counter to third pro) Not easy to debug. example: NullPointerException thrown on server, containing line of erroneous code running on the server.
			# Counter to fifth pro) But there is more overhead - slower
			# Synchronous - wrong model for large, distributed applications, and also bad for users

	==Questions to be discussed==		==Questions to be discussed==

Soma: /* Readings */

2008-01-16T17:39:51Z

Readings

← Older revision		Revision as of 17:39, 16 January 2008
Line 1:		Line 1:
	==Readings==		==Readings==

	~~Papers for Jan~~. ~~21st are~~ [http://homeostasis.scs.carleton.ca/~soma/distos/2008-01-21 ~~here~~].		[http://homeostasis.scs.carleton.ca/~soma/distos/2008-01-21/cheriton-v.pdf David R. Cheriton, "The V Distributed System."]

			[http://homeostasis.scs.carleton.ca/~soma/distos/2008-01-21/walker-locus.pdf Bruce Walker et al., "The LOCUS Distributed Operating System."]

			These two papers describe V and LOCUS, two early distributed operating systems.


			[http://homeostasis.scs.carleton.ca/~soma/distos/2008-01-21/young-mach-dual.pdf Michael Young et al., "The Duality of Memory and Communication in the Implementation of a Multiprocessor Operating System."]

			This paper describes some key ideas behind Mach, a seminal microkernel-based operating system. The design of Mach informs later work in distributed operating systems. For more background on Mach, I suggest reading [http://en.wikipedia.org/wiki/Mach_kernel Wikipedia's article on Mach].

	==Questions to be discussed==		==Questions to be discussed==

Soma at 17:33, 16 January 2008

2008-01-16T17:33:07Z

← Older revision		Revision as of 17:33, 16 January 2008
Line 1:		Line 1:
			==Readings==

	Papers for Jan. 21st are [http://homeostasis.scs.carleton.ca/~soma/distos/2008-01-21 here].		Papers for Jan. 21st are [http://homeostasis.scs.carleton.ca/~soma/distos/2008-01-21 here].

			==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?

Soma at 02:54, 15 January 2008

2008-01-15T02:54:11Z

New page

Papers for Jan. 21st are [http://homeostasis.scs.carleton.ca/~soma/distos/2008-01-21 here].