DistOS 2014W Lecture 7 - Revision history

Cdelahou: Merged Simon's and others notes together. Significant change

2014-02-24T00:43:29Z

Merged Simon's and others notes together. Significant change

@@ Line 7: / Line 7: @@
 * Don't just give a history, tell a story!
 * Do not try to summarize papers.
-* Try to identify a pattern, a common ground between the papers.
+* Try to identify a pattern, a common ground between the papers
 ==UNIX and Plan 9 (Jan. 28)==
@@ Line 17: / Line 30: @@
 == Unix and Plan 9 ==
-UNIX was built as "a castrated version of Multics", which was a very complex system. Multics was, arguably, so far ahead of its time that we are only just achieving their ambitions now. Unix was much more modest, and therefore much more achievable and successful. Just enough infrastructure to avoid reinventing the wheel. Just a couple of programmers making something for their own use. Unix was not designed as product or commercial entity at all. It was licensed out because AT&T was under severe antitrust scrutiny at the time.
+* Multics was a complex system which was bad because it was used less, slower, etc...
+* Multics was not for end users, it was designed to support "utility computing" wherein computation was a service to be charged for
-In Anil's opinion Plan 9's design of using file abstraction to represent Network was n't a good design idea. The reason being file I/O breaking is uncommon but Network has an inherent flakiness and loss of connectivity is normal in networks. Using file system abstractions to represent Network does n't properly takes care of the flakiness inherent in the Network. Put in other words Network does n't have the reliability characteristics of mass storage and how to deal with this fact while using the file abstraction to deal with network was a major question which was left unanswered by the Plan 9 designers. Anil also added that Plan 9 was a elegant attempt at representing everything using file abstraction but they were trying too hard with this approach as pointed out above. In distributed systems the best approach to use is - if things have different semantics then they should have abstractions that reflect their characteristics, the APIs should reflect their characteristics rather than hide it away and try to pretend or treat them as if they were having characteristics of something else in an attempt towards too much generalizations. In Anil's opinion another reason why Plan 9 was not widely adopted was that it was a bit late to the scene, by the time Plan 9 came out in the 90s systems running UNIX with networking was widely adopted driven by the success of Internet.
+UNIX was built as "a castrated version of Multics", which was a very complex system. Multics was, arguably, so far ahead of its time that we are only just achieving their ambitions now. Unix was much more modest, and therefore much more achievable and successful. Just enough infrastructure to avoid reinventing the wheel. Just a couple of programmers making something for their own use.
-Another valuable point Anil mentioned was that for a technology to get adopted and become successful it should serve or address a niche area for which there are no successful incumbents.
+* Just enough infrastructure to run my programs
-== Simon's Notes ==
+They wanted few, simple abstractions so they made everything a file. The only difference amongst most files was that you could use seek on some and not on others. Berkeley promptly broke this abstraction by introducing sockets for networking.
-* project proposal
+Plan 9 finally introduced networking using the right abstractions, but was too late. Arguably the reason the BSD folks didn't use the file abstraction was because of the difference in reliability. SUN microsystems licensed Berkeley Unix and commercialized it. Files are generally reliable, and failures with them are catastrophic so many applications simply didn't include logic to handle such IO errors. Networks are much less reliable and applications have to be able to deal gracefully with timeouts and other errors.
-* UNIX
+In distributed systems the best approach to use is - if things have different semantics then they should have abstractions that reflect their characteristics, the APIs should reflect their characteristics rather than hide it away and try to pretend or treat them as if they were having characteristics of something else in an attempt towards too much generalizations.
-* Plan 9
+In Anil's opinion another reason why Plan 9 was not widely adopted was that it was a bit late to the scene, by the time Plan 9 came out in the 90s systems running UNIX with networking was widely adopted driven by the success of Internet.
-* Tangent about programming languages
+Tangent about programming languages: C was for system programming. Java was for enterprise programming.

Cdelahou: added link to paper and title

2014-02-21T21:49:15Z

added link to paper and title

← Older revision		Revision as of 21:49, 21 February 2014
Line 8:		Line 8:
	* Do not try to summarize papers.		* Do not try to summarize papers.
	* Try to identify a pattern, a common ground between the papers.		* Try to identify a pattern, a common ground between the papers.

			==UNIX and Plan 9 (Jan. 28)==

			* [http://homeostasis.scs.carleton.ca/~soma/distos/fall2008/unix.pdf Dennis M. Ritchie and Ken Thompson, "The UNIX Time-Sharing System" (1974)]
			* [http://homeostasis.scs.carleton.ca/~soma/distos/2014w/presotto-plan9.pdf Presotto et. al, Plan 9, A Distributed System (1991)]
			* [http://homeostasis.scs.carleton.ca/~soma/distos/2014w/pike-plan9.pdf Pike et al., Plan 9 from Bell Labs (1995)]

	== Unix and Plan 9 ==		== Unix and Plan 9 ==

Aschoenr at 15:20, 30 January 2014

2014-01-30T15:20:19Z

← Older revision		Revision as of 15:20, 30 January 2014
Line 19:		Line 19:
	Another valuable point Anil mentioned was that for a technology to get adopted and become successful it should serve or address a niche area for which there are no successful incumbents.		Another valuable point Anil mentioned was that for a technology to get adopted and become successful it should serve or address a niche area for which there are no successful incumbents.

	~~== Simon's Notes ==~~

			== Simon's Notes ==
			'''These notes should be merged with the text above'''

	* project proposal		* project proposal

Sjoy: minor edit

2014-01-28T19:10:17Z

minor edit

← Older revision		Revision as of 19:10, 28 January 2014
Line 11:		Line 11:
	== Unix and Plan 9 ==		== Unix and Plan 9 ==

	UNIX was built as "a castrated version of Multics", which was a very complex system. ~~Multcs~~ was, arguably, so far ahead of its time that we are only just achieving their ambitions now. Unix was much more modest, and therefore much more achievable and successful. Just enough infrastructure to avoid reinventing the wheel. Just a couple of programmers making something for their own use. Unix was not designed as product or commercial entity at all. It was licensed out because AT&T was under severe antitrust scrutiny at the time.		UNIX was built as "a castrated version of Multics", which was a very complex system. Multics was, arguably, so far ahead of its time that we are only just achieving their ambitions now. Unix was much more modest, and therefore much more achievable and successful. Just enough infrastructure to avoid reinventing the wheel. Just a couple of programmers making something for their own use. Unix was not designed as product or commercial entity at all. It was licensed out because AT&T was under severe antitrust scrutiny at the time.

	They wanted few, simple abstractions so they made everything a file. Berkeley promptly broke this abstraction by introducing sockets for networking. Plan 9 finally introduced networking using the right abstractions, but was too late. Arguably the reason the BSD folks didn't use the file abstraction was because of the difference in reliability. SUN microsystems licensed Berkeley Unix and commercialized it. Files are generally reliable, and failures with them are catastrophic so many applications simply didn't include logic to handle such IO errors. Networks are much less reliable and applications have to be able to deal gracefully with timeouts and other errors.		They wanted few, simple abstractions so they made everything a file. Berkeley promptly broke this abstraction by introducing sockets for networking. Plan 9 finally introduced networking using the right abstractions, but was too late. Arguably the reason the BSD folks didn't use the file abstraction was because of the difference in reliability. SUN microsystems licensed Berkeley Unix and commercialized it. Files are generally reliable, and failures with them are catastrophic so many applications simply didn't include logic to handle such IO errors. Networks are much less reliable and applications have to be able to deal gracefully with timeouts and other errors.

Sjoy: additional notes from the lecture

2014-01-28T19:08:54Z

additional notes from the lecture

← Older revision		Revision as of 19:08, 28 January 2014
Line 16:		Line 16:

	In Anil's opinion Plan 9's design of using file abstraction to represent Network was n't a good design idea. The reason being file I/O breaking is uncommon but Network has an inherent flakiness and loss of connectivity is normal in networks. Using file system abstractions to represent Network does n't properly takes care of the flakiness inherent in the Network. Put in other words Network does n't have the reliability characteristics of mass storage and how to deal with this fact while using the file abstraction to deal with network was a major question which was left unanswered by the Plan 9 designers. Anil also added that Plan 9 was a elegant attempt at representing everything using file abstraction but they were trying too hard with this approach as pointed out above. In distributed systems the best approach to use is - if things have different semantics then they should have abstractions that reflect their characteristics, the APIs should reflect their characteristics rather than hide it away and try to pretend or treat them as if they were having characteristics of something else in an attempt towards too much generalizations. In Anil's opinion another reason why Plan 9 was not widely adopted was that it was a bit late to the scene, by the time Plan 9 came out in the 90s systems running UNIX with networking was widely adopted driven by the success of Internet.		In Anil's opinion Plan 9's design of using file abstraction to represent Network was n't a good design idea. The reason being file I/O breaking is uncommon but Network has an inherent flakiness and loss of connectivity is normal in networks. Using file system abstractions to represent Network does n't properly takes care of the flakiness inherent in the Network. Put in other words Network does n't have the reliability characteristics of mass storage and how to deal with this fact while using the file abstraction to deal with network was a major question which was left unanswered by the Plan 9 designers. Anil also added that Plan 9 was a elegant attempt at representing everything using file abstraction but they were trying too hard with this approach as pointed out above. In distributed systems the best approach to use is - if things have different semantics then they should have abstractions that reflect their characteristics, the APIs should reflect their characteristics rather than hide it away and try to pretend or treat them as if they were having characteristics of something else in an attempt towards too much generalizations. In Anil's opinion another reason why Plan 9 was not widely adopted was that it was a bit late to the scene, by the time Plan 9 came out in the 90s systems running UNIX with networking was widely adopted driven by the success of Internet.

			Another valuable point Anil mentioned was that for a technology to get adopted and become successful it should serve or address a niche area for which there are no successful incumbents.

	== Simon's Notes ==		== Simon's Notes ==

Sjoy: additional notes from the lecture

2014-01-28T18:59:26Z

additional notes from the lecture

← Older revision		Revision as of 18:59, 28 January 2014
Line 6:		Line 6:
	* Find papers that cite that paper, papers it cites, etc. to collect a body of related work.		* Find papers that cite that paper, papers it cites, etc. to collect a body of related work.
	* Don't just give a history, tell a story!		* Don't just give a history, tell a story!
			* Do not try to summarize papers.
			* Try to identify a pattern, a common ground between the papers.

	== Unix and Plan 9 ==		== Unix and Plan 9 ==

	UNIX was built as "a castrated version of ~~Multix~~", which was a very complex system. ~~Multix~~ was, arguably, so far ahead of its time that we are only just achieving their ambitions now. Unix was much more modest, and therefore much more achievable and successful. Just enough infrastructure to avoid reinventing the wheel. Just a couple of programmers making something for their own use. Unix was not designed as product or commercial entity at all. It was licensed out because AT&T was under severe antitrust scrutiny at the time.		UNIX was built as "a castrated version of Multics", which was a very complex system. Multcs was, arguably, so far ahead of its time that we are only just achieving their ambitions now. Unix was much more modest, and therefore much more achievable and successful. Just enough infrastructure to avoid reinventing the wheel. Just a couple of programmers making something for their own use. Unix was not designed as product or commercial entity at all. It was licensed out because AT&T was under severe antitrust scrutiny at the time.

	They wanted few, simple abstractions so they made everything a file. Berkeley promptly broke this abstraction by introducing sockets for networking. Plan 9 finally introduced networking using the right abstractions, but was too late. Arguably the reason the BSD folks didn't use the file abstraction was because of the difference in reliability. Files are generally reliable, and failures with them are catastrophic so many applications simply didn't include logic to handle such IO errors. Networks are much less reliable and applications have to be able to deal gracefully with timeouts and other errors.		They wanted few, simple abstractions so they made everything a file. Berkeley promptly broke this abstraction by introducing sockets for networking. Plan 9 finally introduced networking using the right abstractions, but was too late. Arguably the reason the BSD folks didn't use the file abstraction was because of the difference in reliability. SUN microsystems licensed Berkeley Unix and commercialized it. Files are generally reliable, and failures with them are catastrophic so many applications simply didn't include logic to handle such IO errors. Networks are much less reliable and applications have to be able to deal gracefully with timeouts and other errors.

			In Anil's opinion Plan 9's design of using file abstraction to represent Network was n't a good design idea. The reason being file I/O breaking is uncommon but Network has an inherent flakiness and loss of connectivity is normal in networks. Using file system abstractions to represent Network does n't properly takes care of the flakiness inherent in the Network. Put in other words Network does n't have the reliability characteristics of mass storage and how to deal with this fact while using the file abstraction to deal with network was a major question which was left unanswered by the Plan 9 designers. Anil also added that Plan 9 was a elegant attempt at representing everything using file abstraction but they were trying too hard with this approach as pointed out above. In distributed systems the best approach to use is - if things have different semantics then they should have abstractions that reflect their characteristics, the APIs should reflect their characteristics rather than hide it away and try to pretend or treat them as if they were having characteristics of something else in an attempt towards too much generalizations. In Anil's opinion another reason why Plan 9 was not widely adopted was that it was a bit late to the scene, by the time Plan 9 came out in the 90s systems running UNIX with networking was widely adopted driven by the success of Internet.

	== Simon's Notes ==		== Simon's Notes ==

Sdp: update simon's notes at the end of class

2014-01-28T16:14:47Z

update simon's notes at the end of class

← Older revision		Revision as of 16:14, 28 January 2014
Line 14:		Line 14:

	== Simon's Notes ==		== Simon's Notes ==


	* project proposal		* project proposal
Line 54:		Line 55:
	** opinions		** opinions
	*** things that have different failure modes deserve different APIs		*** things that have different failure modes deserve different APIs
			** niche?
			*** they never found one


			* Tangent about programming languages
			** C was for system programming
			** Java was for enterprise programming

Sdp: formatting

2014-01-28T16:00:54Z

formatting

← Older revision		Revision as of 16:00, 28 January 2014
Line 27:		Line 27:
	** Pick a conference (usenix is pretty systems oriented, maybe Lisa), go through their papers and find something interesting		** Pick a conference (usenix is pretty systems oriented, maybe Lisa), go through their papers and find something interesting
	** tell a story that connects several papers in the topic you choose		** tell a story that connects several papers in the topic you choose


	* UNIX		* UNIX

Sdp: fixed a bug

2014-01-28T16:00:37Z

fixed a bug

← Older revision		Revision as of 16:00, 28 January 2014
Line 25:		Line 25:
	*** distributed databases (potentially)		*** distributed databases (potentially)
	*** anonymity systems		*** anonymity systems
	** Pick a conference (usenix is pretty systems oriented, maybe Lisa),		** Pick a conference (usenix is pretty systems oriented, maybe Lisa), go through their papers and find something interesting
	go through their papers and find something interesting
	** tell a story that connects several papers in the topic you choose		** tell a story that connects several papers in the topic you choose

Sdp: added simon's notes to be merged in later

2014-01-28T16:00:18Z

added simon's notes to be merged in later

← Older revision		Revision as of 16:00, 28 January 2014
Line 12:		Line 12:

	They wanted few, simple abstractions so they made everything a file. Berkeley promptly broke this abstraction by introducing sockets for networking. Plan 9 finally introduced networking using the right abstractions, but was too late. Arguably the reason the BSD folks didn't use the file abstraction was because of the difference in reliability. Files are generally reliable, and failures with them are catastrophic so many applications simply didn't include logic to handle such IO errors. Networks are much less reliable and applications have to be able to deal gracefully with timeouts and other errors.		They wanted few, simple abstractions so they made everything a file. Berkeley promptly broke this abstraction by introducing sockets for networking. Plan 9 finally introduced networking using the right abstractions, but was too late. Arguably the reason the BSD folks didn't use the file abstraction was because of the difference in reliability. Files are generally reliable, and failures with them are catastrophic so many applications simply didn't include logic to handle such IO errors. Networks are much less reliable and applications have to be able to deal gracefully with timeouts and other errors.

			== Simon's Notes ==

			* project proposal
			** We will discuss the primary papers we've chosen on Thursday, February 6th
			* possible papers, remember to pick a topic you have some chance of understanding
			** OSDI 2012
			*** datacenter (filesystems for doing X, heat management, etc...)
			*** web stuff
			*** distributed shared memory
			*** distributed network I/O infrastructure
			*** distributed databases (potentially)
			*** anonymity systems
			** Pick a conference (usenix is pretty systems oriented, maybe Lisa),
			go through their papers and find something interesting
			** tell a story that connects several papers in the topic you choose

			* UNIX
			** Relation to multics
			*** Multics was a complex system which was bad because it was used less, slower, etc...
			*** Multics was not for end users, it was designed to support "utility computing" wherein computation was a service to be charged for
			** What?
			*** Just enough infrastructure to run my programs
			*** It was really just supposed to be used by programmers
			*** "By programmers for programmers"
			*** Software and source licensed for a nominal fee
			*** "Everything is a file"
			*** only difference was files that you could use seek or ones you couldn't
			*** simple abstractions
			** Networking
			*** Berkeley folks made sockets, not files which upset the folks at Bell labs
			*** Networks aren't exactly like files because they're unreliable


			* Plan 9
			** major ideas
			*** procfs, later adopted by linux
			** summary
			*** a very elegant attempt to follow the philosophy "everything is a file"
			*** trying too hard
			** opinions
			*** things that have different failure modes deserve different APIs