<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://homeostasis.scs.carleton.ca/wiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Ronak</id>
	<title>Soma-notes - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://homeostasis.scs.carleton.ca/wiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Ronak"/>
	<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php/Special:Contributions/Ronak"/>
	<updated>2026-04-24T16:01:44Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.42.1</generator>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_19&amp;diff=19096</id>
		<title>DistOS 2014W Lecture 19</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_19&amp;diff=19096"/>
		<updated>2014-04-26T01:26:34Z</updated>

		<summary type="html">&lt;p&gt;Ronak: /* Bigtable */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Dynamo ==&lt;br /&gt;
&lt;br /&gt;
* Key value-store.&lt;br /&gt;
* Query model: key-value only&lt;br /&gt;
* Highly available, always writable.&lt;br /&gt;
* Guarantee Service Level Agreements (SLA).&lt;br /&gt;
* 0-hop DHT: it has direct link to the destination. Has complete view of system locally. No dynamic routing.&lt;br /&gt;
* Dynamo sacrifices consistency under certain failure scenarios.&lt;br /&gt;
* Consistent hashing to partition key-space: the output range of a hash function is treated as a fixed circular space or “ring”.&lt;br /&gt;
* Key-space is linear and the nodes partition it.&lt;br /&gt;
* ”Virtual Nodes”: Each server can be responsible for more than one virtual node.&lt;br /&gt;
* Each data item is replicated at N hosts.&lt;br /&gt;
* “preference list”: The list of nodes that is responsible for storing a particular key.&lt;br /&gt;
* Sacrifice strong consistency for availability.&lt;br /&gt;
** Eventual consistency.&lt;br /&gt;
* Decentralized, P2P, limited administration.&lt;br /&gt;
* it work with 100 servers,it is not bigger.&lt;br /&gt;
* Application/client specific conflict resolution.&lt;br /&gt;
* Designed to be flexible&lt;br /&gt;
** &amp;quot;Tuneable consistency&amp;quot;&lt;br /&gt;
** Pluggable local persistence: DBD, MySQL.&lt;br /&gt;
&lt;br /&gt;
Amazon&#039;s motivating use case is that at no point, in a customer&#039;s shopping cart, should any newly added item be dropped. Dynamo should be highly available and always writeable.&lt;br /&gt;
&lt;br /&gt;
Amazon has an service oriented architecture. A response to a client is a composite of many services, so SLA&#039;s were a HUGE consideration when designing Dynamo. Amazon needed low latency and high availability to ensure a good user experience when aggregating all the services together.&lt;br /&gt;
&lt;br /&gt;
Traditional RDBMS emphasise ACID compliance. Amazon found that ACID compliancy lead to systems with far less availability. It&#039;s hard to have consistency and availability both at the same time. See [http://en.wikipedia.org/wiki/CAP_theorem CAP Theorem]. Dynamo can, and usually does sacrifice consistency for availability. They use the terms &amp;quot;eventual consistency&amp;quot; and &amp;quot;tunable consistency&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
Key range is partitioned according to consistent hashing algorithm,which treats the output range as a fixed circular space or “ring”. Any time a new node joins in, it takes a token which decides its position on the ring. Every node becomes owner of key range which is in between itself and the previous node on the ring, so anytime a node comes in or leaves it only affects its neighbor nodes. Dynamo has this notion of virtual node, where a machine actually can host more than one node and hence allows to adjust the load according to the machine&#039;s capability. &lt;br /&gt;
&lt;br /&gt;
Dynamo uses replication to provide availability, each key-value is distributed to N-1 node (N can be configured by the application that uses Dynamo).&lt;br /&gt;
&lt;br /&gt;
Each node has a complete view of the network. A node knows the key-range that every node supports.  Any time a node joins, the gossip based protocols are used to inform every node about the key range changes. This allows for Dynamo to be a 0-hop network. 0-hop means it is logically 0 hop network. IP routing is still be required to actually physically get to the node. This 0-hop approach is different from typical distributed hash tables where routing and hops are used to find the node responsible for a key (eg. Tapestry). Dynamo can do this because the system is deployed on trusted, fully known, networks.&lt;br /&gt;
&lt;br /&gt;
Dynamo is deployed on trusted networks (ie. for amazon&#039;s internal applications. It doesn&#039;t have to worry about making the system secure. Compare this to Oceanstore.&lt;br /&gt;
&lt;br /&gt;
When compared to BigTable, Dynamo typically scales to hundreds of servers, not thousands. That is not to say that Dynamo can not scale, we need to understand the difference between the use cases for BigTable and Dynamo.&lt;br /&gt;
&lt;br /&gt;
Any &amp;quot;write&amp;quot; that is done on any replica is never held off to serialize the updates to maintain consistency, it will eventually try to reconcile the difference between two different versions( based on the logs) if it can not do so, the conflict resolution is left to the client application which would read data from Dynamo(If there are more than versions of a replica, all the versions along with the log is passed to client and client should reconcile the changes)&lt;br /&gt;
&lt;br /&gt;
== Bigtable ==&lt;br /&gt;
&lt;br /&gt;
* Bigtable is a distributed storage system for managing structured data that is designed to scale to a very large size: petabytes of data across thousands of commodity servers.&lt;br /&gt;
* Designed to scale to a very large size&lt;br /&gt;
* More focused on consistency than Dynamo. &lt;br /&gt;
* Bigtable has achieved several goals: wide applicability, scalability, high performance, and high availability.&lt;br /&gt;
&lt;br /&gt;
* A BigTable is a sparse, distributed persistent multi-dimensional sorted map.The map is indexed by a row key, column key, and a timestamp; each value in the map is an uninterpreted array of bytes.&lt;br /&gt;
* Column oriented DB.&lt;br /&gt;
** Streaming chunks of columns is easier than streaming entire rows.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
* Data Model: rows made up of column families.Bigtable also treats data as uninterpreted strings, although clients often serialize various forms of structured and semi-structured data into these strings.&lt;br /&gt;
* The row range for a table is dynamically partitioned. Each row range is called a tablet, which is the unit of distribution and load balancing.&lt;br /&gt;
** Eg. Row: the page URL. Column families would either be the content, or the set of inbound links.&lt;br /&gt;
** Each column in a column family has copies. Timestamped.&lt;br /&gt;
* Bigtable schema parameters let clients dynamically control whether to serve data out of memory or from disk.&lt;br /&gt;
* Bigtable uses the distributed Google File System (GFS) to store log and data �files.&lt;br /&gt;
&lt;br /&gt;
* Tablets: Large tables broken into tablets at row boundaries and each raw Tablet holds contiguous range of sorted rows.&lt;br /&gt;
** Immutable b/c of GFS. Deletion happens via garbage collection.&lt;br /&gt;
&lt;br /&gt;
* An SSTable provides a persistent,ordered immutable map from keys to values, where both keys and values are arbitrary byte strings.&lt;br /&gt;
* Metadata operations: Create/delete tables, column families, change metadata.&lt;br /&gt;
&lt;br /&gt;
===Implementation:===&lt;br /&gt;
&lt;br /&gt;
* Centralized, hierchy.&lt;br /&gt;
* Three major components: client library, one master server, many tablet servers.&lt;br /&gt;
&lt;br /&gt;
* Master server&lt;br /&gt;
** Assigns tablets to tablet server.&lt;br /&gt;
** Detects tablet additions and removals&lt;br /&gt;
** garbage collection on GFS.&lt;br /&gt;
* balancing tablet-server load&lt;br /&gt;
*it handles schema changes such as table and column family creations.&lt;br /&gt;
&lt;br /&gt;
* Tablet Servers&lt;br /&gt;
** holds tablet locations.&lt;br /&gt;
** Manages multiple tablets (thousands per tablet server)&lt;br /&gt;
** Handles I/O.&lt;br /&gt;
&lt;br /&gt;
* Client Library&lt;br /&gt;
** What devs use.&lt;br /&gt;
** Caches tablet locations&lt;br /&gt;
&lt;br /&gt;
=== Tablet Serving ===&lt;br /&gt;
&lt;br /&gt;
* The persistent state of a tablet is stored in GFS&lt;br /&gt;
* Updates are committed to a commit log that stores redo records. &lt;br /&gt;
* the recently committed ones are stored in memory in a sorted buffer called a memtable&lt;br /&gt;
* the older updates are stored in a sequence of SSTables. &lt;br /&gt;
* To recover a tablet, a tablet server reads its metadata from the METADATA table. &lt;br /&gt;
* This metadata contains the list of SSTables that comprise a tablet and a set of a redo points, which are pointers into any commit logs that may contain data for the tablet. &lt;br /&gt;
* The server reads the indices of the SSTables into memory and reconstructs the memtable by applying all of the updates that have committed since the redo points.&lt;br /&gt;
* When the memtable size reaches a threshold, the memtable is frozen, a new memtable is created, and the frozen memtable is converted to an SSTable and written to GFS.&lt;br /&gt;
&lt;br /&gt;
=== Caching ===&lt;br /&gt;
&lt;br /&gt;
To improve read performance, tablet servers use two levels of caching. &lt;br /&gt;
&lt;br /&gt;
* The Scan Cache is a higher-level cache that caches the key-value pairs returned by the SSTable interface to the tablet server code. The Scan Cache is most useful for applications that tend to read the same data repeatedly.&lt;br /&gt;
* The Block Cache is a lower-level cache that caches SSTables blocks that were read from GFS. The Block Cache is useful for applications that tend to read data that is close to the data they recently read&lt;br /&gt;
&lt;br /&gt;
Apart from that,Bigtable relies on a highly-available and persistent distributed lock service called Chubby.Bigtable uses Chubby for a variety of tasks: to ensure that there is at most one active master at any time; to store the bootstrap location of Bigtable data to discover tablet servers and �finalize tablet server deaths to store Bigtable schema information and to store access control lists.&lt;br /&gt;
&lt;br /&gt;
To reduce the number of accesses by allowing clients to specify that Bloom �filters .A Bloom �filter allows us to ask whether an SSTable might contain any data for a specifi�ed row/column pair. For certain applications, a small amount of tablet server memory used for storing Bloom&lt;br /&gt;
�filters drastically reduces the number of disk seeks required for read operations.&lt;br /&gt;
&lt;br /&gt;
=== Consider the following ===&lt;br /&gt;
&lt;br /&gt;
Can big table be used in a shopping cart type of scenario, where low latency and availability are the main focus. Can it be used like Dynamo? Yes, it can, but not as well. Big Table would have more latency because it was designed for Data procession and was not designed to work under such a scenario. Dynamo was designed for different use cases. There is no one solution that can solve all the problems in the world of distributed file systems, there is no silver bullet, no - one size fits all. File systems are usually designed for specific use cases and they work best for them, later if the need be they can be molded to work on other scenarios as well and they may provide good enough performance for the later added goals as well but they would work best for the use cases,which were the targets in the beginnings.&lt;br /&gt;
&lt;br /&gt;
* BigTable -&amp;gt; Highly consistent, Data Processing, Map Reduce, semi structured store&lt;br /&gt;
* Dynamo -&amp;gt; High availability, low latency, key-value store&lt;br /&gt;
&lt;br /&gt;
== General talk ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
* Read the introduction and conclusion for each paper and think about cases in the paper more than look to how the author solve the problem.&lt;/div&gt;</summary>
		<author><name>Ronak</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_21&amp;diff=19095</id>
		<title>DistOS 2014W Lecture 21</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_21&amp;diff=19095"/>
		<updated>2014-04-25T09:21:15Z</updated>

		<summary type="html">&lt;p&gt;Ronak: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Presentation ==&lt;br /&gt;
&lt;br /&gt;
=== Marking ===&lt;br /&gt;
&lt;br /&gt;
* marked mostly on presentation, not content&lt;br /&gt;
* basically we want to communicate the basic structure of the paper, and do so in a way that isn&#039;t boring&lt;br /&gt;
&lt;br /&gt;
=== Content ===&lt;br /&gt;
&lt;br /&gt;
* concrete, not &amp;quot;head in the clouds&amp;quot;&lt;br /&gt;
* present the area&lt;br /&gt;
* compare and contrast the papers&lt;br /&gt;
* 10 minutes talk, 5 minutes feedback&lt;br /&gt;
* basic argument&lt;br /&gt;
* basic references&lt;br /&gt;
&lt;br /&gt;
=== Form ===&lt;br /&gt;
&lt;br /&gt;
* show the work we&#039;ve done on paper&lt;br /&gt;
* try to get feedback&lt;br /&gt;
* think of it as a rough draft&lt;br /&gt;
* try to get people to read the paper&lt;br /&gt;
* enthusiasm&lt;br /&gt;
* powerpoints are easier&lt;br /&gt;
* don&#039;t read slides&lt;br /&gt;
* no whole sentences on slides&lt;br /&gt;
* look at talks by Mark Shuttleworth&lt;br /&gt;
&lt;br /&gt;
== MapReduce ==&lt;br /&gt;
&lt;br /&gt;
MapReduce is a programming model and an associated implementation for processing and generating large data sets.A clever observation that a simple solution could solve most distributed problems.  It&#039;s all about programming to an abstraction that is efficiently parallelizable.  Note that it&#039;s not actually a simple solution, because it sits atop a mountain of code.  It requires something like BigTable which requires something like GFS, which requires something like Chubby. Despite this, it allows for programmers to easily do distributed computation using a simple framework that hides the messy details of parrallelization.&lt;br /&gt;
&lt;br /&gt;
* Restricted programming model&lt;br /&gt;
* Interestingly large scale problems can be implemented with this&lt;br /&gt;
* Easy to program, powerful for certain classes of problems, it scales well.&lt;br /&gt;
* MapReduce job model is VERY limited though. You can&#039;t do things like  simulations.&lt;br /&gt;
* MapReduce is problem specific. &lt;br /&gt;
** Naiad is less problem specific and allows you to do more.&lt;br /&gt;
&lt;br /&gt;
Programming to an abstraction that is efficiently parllel. We have learnt all about infrastructure until now. &lt;br /&gt;
Classic OS abstractions were about files. Now we used programming abstraction.&lt;br /&gt;
&lt;br /&gt;
Example: word frequency in a document.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== How does it work? ===&lt;br /&gt;
&lt;br /&gt;
* Two steps. Map and Reduce. The user writes theses.&lt;br /&gt;
** Map takes a single input key-value pair (eg. a named document) and converts it to an intermediate (k,v) representation. A list of new key-values.&lt;br /&gt;
** Reduce: Take the intermediate representation and merge the values.&lt;br /&gt;
&lt;br /&gt;
Programs written in this functional style are automatically parallelized and executed on a large cluster of commodity machines. The run-time system takes care of the details of partitioning the input data, scheduling the program&#039;s execution across a set of machines, handling machine&lt;br /&gt;
failures, and managing the required inter-machine communication.&lt;br /&gt;
&lt;br /&gt;
=== Execution ===&lt;br /&gt;
&lt;br /&gt;
When the user program calls the MapReduce function, the following sequence of actions occurs.&lt;br /&gt;
&lt;br /&gt;
* splits the input �files into M pieces of typically&lt;br /&gt;
* starts up many copies of the program on a cluster of machines&lt;br /&gt;
* One of the copies of the program is special  the master. The rest are workers that are assigned work by the master.&lt;br /&gt;
* A worker who is assigned a map task reads the contents of the corresponding input split. It parses key/value pairs out of the input data and passes each pair to the user-de�fined Map function.&lt;br /&gt;
* Periodically, the buffered pairs are written to local disk, partitioned into R regions by the partitioning function. The locations of these buffered pairs on the local disk are passed back to the master, who is responsible for forwarding these locations to the reduce workers.&lt;br /&gt;
* The reduce worker iterates over the sorted intermediate data and for each unique intermediate key encountered, it passes the key and the corresponding set of intermediate values to the user&#039;s Reduce function.&lt;br /&gt;
* When all map tasks and reduce tasks have been completed, the master wakes up the user program.&lt;br /&gt;
* After successful completion, the output of the mapreduce execution is available in the R output �files.&lt;br /&gt;
&lt;br /&gt;
The master keeps several data structures. For each map task and reduce task, it stores the state (idle, in-progress, or completed), and the identity of the worker machine (for non-idle tasks).&lt;br /&gt;
&lt;br /&gt;
=== Fault Tolerance ===&lt;br /&gt;
&lt;br /&gt;
The master pings every worker periodically. If no response is received from a worker in a certain amount of time, the master marks the worker as failed. Any map tasks completed by the worker are reset back to their initial idle state, and therefore become eligible for scheduling&lt;br /&gt;
on other workers.&lt;br /&gt;
&lt;br /&gt;
In case of Master Failure, It is easy to make the master write periodic checkpoints of the master data structures described above. If the master task dies, a new copy can be started from the last checkpointed state.&lt;br /&gt;
&lt;br /&gt;
=== Implementation ===&lt;br /&gt;
&lt;br /&gt;
* Uses commodity HW and GFS.&lt;br /&gt;
* Master/Slave relationship amongst machines. Master delegates tasks to slaves.&lt;br /&gt;
* Intermediate representation saved as files.&lt;br /&gt;
* Many MapReduce jobs can happen in sequence.&lt;br /&gt;
&lt;br /&gt;
== Naiad ==&lt;br /&gt;
&lt;br /&gt;
Where MapReduce was suited for a specific family of solutions, Naiad tries to generalize the solution to apply parallelization to a much wider family.  Naiad supports MapReduce style solutions, but also many other solutions.  However, the tradeoff was simplicity.  It&#039;s like we took MapReduce and took away its low barrier to entry.  The idea is to create a constrained graph that can easily be parallelized.&lt;br /&gt;
&lt;br /&gt;
* More complicated than Map Reduce&lt;br /&gt;
* Talks about Timely dataflow graphs &lt;br /&gt;
* Its all about Graph algorithms - Graph abstraction&lt;br /&gt;
* Restrictions on graphs so that they can be mapped to parllel computation&lt;br /&gt;
* How to fit anything to this model is a big question. &lt;br /&gt;
* More general than map reduce.&lt;br /&gt;
&lt;br /&gt;
* After reading the MapReduce paper, you could easily write a map reduce job. After reading the Naiad, you can&#039;t. Naiad is super complicated. &lt;br /&gt;
* Their model is super complicated. It doesn&#039;t minimize our cognitive load.&lt;br /&gt;
* Doesn&#039;t scale at all. After about 40 nodes, there is no improvement in performance. MapReduce can scale to thousands of nodes and scales forever.&lt;br /&gt;
* Nobody wants to use it because the abstraction is complicated.&lt;/div&gt;</summary>
		<author><name>Ronak</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_15&amp;diff=19094</id>
		<title>DistOS 2014W Lecture 15</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_15&amp;diff=19094"/>
		<updated>2014-04-25T08:57:52Z</updated>

		<summary type="html">&lt;p&gt;Ronak: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Designing Exercise&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Can we do any kind of distributed system without crypto? We can&#039;t trust crypto...&lt;br /&gt;
&lt;br /&gt;
What are the main features we need to consider for such a system ? &lt;br /&gt;
*Limited Sharing&lt;br /&gt;
*Integrity&lt;br /&gt;
*Availability&lt;br /&gt;
&lt;br /&gt;
Perhaps probabilistically...&lt;br /&gt;
&lt;br /&gt;
Want to be able to put data in, have it distributed, and be able to get it out on some other machine. This kind of sharing would need identification or authentication process.&lt;br /&gt;
&lt;br /&gt;
Availability: &amp;quot;distribute the crap out of it&amp;quot;, doesn&#039;t need crypto. No corruption of data. &lt;br /&gt;
&lt;br /&gt;
Integrity: hashing, but we assume hashes can be forged. If we want to know that we got the same file, then simply send each other the file and compare.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Big Takeaway&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Everything you do with crypto is a refinement of what you can already do in&lt;br /&gt;
weaker forms with weaker assumptions.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Note on Project Proposal&#039;&#039;&#039; &lt;br /&gt;
* Date has been extended until next week. As Prof said some of the proposals are not completely up to mark.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Farsite&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
This paper describes Farsite, a serverless distributed file system that logically functions as a centralized file server but whose physical realization is dispersed among a network of untrusted desktop workstations. Farsite is intended to provide both the benefits of a&lt;br /&gt;
central file server (a shared namespace, locationtransparent access, and reliable data storage) and the benefits of local desktop file systems (low cost, privacy from nosy sysadmins, and resistance to geographically localized faults).Farsite provides file availability and reliability through randomized replicated storage; it ensures the secrecy of file contents with cryptographic techniques; it maintains the integrity of&lt;br /&gt;
file and directory data with a Byzantine-fault-tolerant protocol.It achieves good performance by locally caching file data, lazily propagating file updates, and varying the duration and granularity of content leases.It requires no central administration to maintain.&lt;br /&gt;
&lt;br /&gt;
Goal in designing Farsite is to harness the collective resources of loosely coupled, insecure, and unreliable machines to provide logically centralized, secure, and reliable file-storage service. Farsite system protects and preserves file data and directory metadata primarily through the techniques of cryptography and replication.&lt;br /&gt;
&lt;br /&gt;
Farsite is not a high-speed parallel I/O system.&lt;br /&gt;
Farsite manages trust using public-key-cryptographic certificates.&lt;br /&gt;
&lt;br /&gt;
An important assumption they mentioned is files are both read by many users and also frequently updated by at least one user which is a disadvantage in Farsite.Two technology trends are fundamental in rendering Farsite&#039;s design practical:The large amount of unused disk capacity enables the use of replication for reliability, and the relatively low cost of strong cryptography enables distributed security. Every machine in Farsite may perform three roles: It is a client, a member of a directory group, and afile host. A client is a machine that directly interacts with a user. A directory group is a set of machines that collectively manage file information using a Byzantine-fault-tolerant protocol. Every member of the group stores a replica of the information, and as the group receives client requests, each member processes these requests deterministically, updates its replica, and sends replies to the client.When a client wishes to read a file, it sends a&lt;br /&gt;
message to the directory group, which replies with the contents of the requested file. If the client updates the file, it sends the update to the directory group.&lt;br /&gt;
&lt;br /&gt;
When a client wishes to read a file, it sends a message to the directory group, which replies with the contents of the requested file. Advantage of Farsite are (1)It adds local caching of file content on the client to improve read performance. (2)Farsite delays pushing updates to the directory group, because most file writes are deleted or overwritten shortly after they occur. (3)Performing encryption on a block level enables a client to write an individual block without having to rewrite the entire file. It also enables the client to read individual blocks without having to wait for the download of an entire file from a file host.&lt;br /&gt;
&lt;br /&gt;
Farsite achieves reliability (long-term data persistence) and availability (immediate accessibility of file data when requested) mainly through replication.&lt;br /&gt;
&lt;br /&gt;
The Farsite design uses two main mechanisms to keep a node&#039;s computation, communication, and storage from growing with the system size: hint-based pathname translation and delayed directory-change notification.&lt;/div&gt;</summary>
		<author><name>Ronak</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_15&amp;diff=19093</id>
		<title>DistOS 2014W Lecture 15</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_15&amp;diff=19093"/>
		<updated>2014-04-25T07:46:59Z</updated>

		<summary type="html">&lt;p&gt;Ronak: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Designing Exercise&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Can we do any kind of distributed system without crypto? We can&#039;t trust crypto...&lt;br /&gt;
&lt;br /&gt;
What are the main features we need to consider for such a system ? &lt;br /&gt;
*Limited Sharing&lt;br /&gt;
*Integrity&lt;br /&gt;
*Availability&lt;br /&gt;
&lt;br /&gt;
Perhaps probabilistically...&lt;br /&gt;
&lt;br /&gt;
Want to be able to put data in, have it distributed, and be able to get it out on some other machine. This kind of sharing would need identification or authentication process.&lt;br /&gt;
&lt;br /&gt;
Availability: &amp;quot;distribute the crap out of it&amp;quot;, doesn&#039;t need crypto. No corruption of data. &lt;br /&gt;
&lt;br /&gt;
Integrity: hashing, but we assume hashes can be forged. If we want to know that we got the same file, then simply send each other the file and compare.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Big Takeaway&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Everything you do with crypto is a refinement of what you can already do in&lt;br /&gt;
weaker forms with weaker assumptions.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Note on Project Proposal&#039;&#039;&#039; &lt;br /&gt;
* Date has been extended until next week. As Prof said some of the proposals are not completely up to mark.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Farsite&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
This paper describes Farsite, a serverless distributed file system that logically functions as a centralized file server but whose physical realization is dispersed among a network of untrusted desktop workstations. Farsite is intended to provide both the benefits of a&lt;br /&gt;
central file server (a shared namespace, locationtransparent access, and reliable data storage) and the benefits of local desktop file systems (low cost, privacy from nosy sysadmins, and resistance to geographically localized faults).Farsite provides file availability and reliability through randomized replicated storage; it ensures the secrecy of file contents with cryptographic techniques; it maintains the integrity of&lt;br /&gt;
file and directory data with a Byzantine-fault-tolerant protocol.It achieves good performance by locally caching file data, lazily propagating file updates, and varying the duration and granularity of content leases.It requires no central administration to maintain.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
An important assumption they mentioned is files are both read by many users and also frequently updated by at least one user which is a disadvantage in Farsite.Two technology trends are fundamental in rendering Farsite&#039;s design practical:The large amount of unused disk capacity enables the use of replication for reliability, and the relatively low cost of strong cryptography enables distributed security.&lt;br /&gt;
Every machine in Farsite may perform three roles: It is a client, a member of a directory group, and afile host. A client is a machine that directly interacts with a user. A directory group is a set of machines that collectively manage file information using a Byzantine-fault-tolerant protocol. Every member of the group stores a replica of the information, and as the group receives client requests,&lt;br /&gt;
each member processes these requests deterministically, updates its replica, and sends replies to the client.&lt;br /&gt;
&lt;br /&gt;
When a client wishes to read a file, it sends a message to the directory group, which replies with the&lt;br /&gt;
contents of the requested file.&lt;br /&gt;
Advantage of Farsite are (1)It adds local caching of file content on the client to improve read performance. (2)Farsite delays pushing updates to the directory group, because most file writes are deleted or overwritten shortly after they occur. (3)Performing encryption on a block level enables a client to write an individual block without having to rewrite the entire file. It also enables the client to read individual blocks without having to wait for the download of an entire file from a file host.&lt;/div&gt;</summary>
		<author><name>Ronak</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_15&amp;diff=19092</id>
		<title>DistOS 2014W Lecture 15</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_15&amp;diff=19092"/>
		<updated>2014-04-25T03:55:04Z</updated>

		<summary type="html">&lt;p&gt;Ronak: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Designing Exercise&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Can we do any kind of distributed system without crypto? We can&#039;t trust crypto...&lt;br /&gt;
&lt;br /&gt;
What are the main features we need to consider for such a system ? &lt;br /&gt;
*Limited Sharing&lt;br /&gt;
*Integrity&lt;br /&gt;
*Availability&lt;br /&gt;
&lt;br /&gt;
Perhaps probabilistically...&lt;br /&gt;
&lt;br /&gt;
Want to be able to put data in, have it distributed, and be able to get it out on some other machine. This kind of sharing would need identification or authentication process.&lt;br /&gt;
&lt;br /&gt;
Availability: &amp;quot;distribute the crap out of it&amp;quot;, doesn&#039;t need crypto. No corruption of data. &lt;br /&gt;
&lt;br /&gt;
Integrity: hashing, but we assume hashes can be forged. If we want to know that we got the same file, then simply send each other the file and compare.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Big Takeaway&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Everything you do with crypto is a refinement of what you can already do in&lt;br /&gt;
weaker forms with weaker assumptions.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Note on Project Proposal&#039;&#039;&#039; &lt;br /&gt;
* Date has been extended until next week. As Prof said some of the proposals are not completely up to mark.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Farsite&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
This paper describes Farsite, a serverless distributed file system that logically functions as a centralized file server but whose physical realization is dispersed among a network of untrusted desktop workstations.&lt;br /&gt;
An important assumption they mentioned is files are both read by many users and also frequently updated by at least one user which is a disadvantage in Farsite.&lt;br /&gt;
Two technology trends are fundamental in rendering Farsite&#039;s design practical:The large amount of unused disk capacity enables the use of replication for reliability, and the relatively low cost of strong cryptography enables distributed security.&lt;br /&gt;
Every machine in Farsite may perform three roles: It is a client, a member of a directory group, and afile host. A client is a machine that directly interacts with a user. A directory group is a set of machines that collectively manage file information using a Byzantine-fault-tolerant protocol. Every member of the group stores a replica of the information, and as the group receives client requests,&lt;br /&gt;
each member processes these requests deterministically, updates its replica, and sends replies to the client.&lt;br /&gt;
&lt;br /&gt;
When a client wishes to read a file, it sends a message to the directory group, which replies with the&lt;br /&gt;
contents of the requested file.&lt;br /&gt;
Advantage of Farsite are (1)It adds local caching of file content on the client to improve read performance. (2)Farsite delays pushing updates to the directory group, because most file writes are deleted or overwritten shortly after they occur. (3)Performing encryption on a block level enables a client to write an individual block without having to rewrite the entire file. It also enables the client to read individual blocks without having to wait for the download of an entire file from a file host.&lt;/div&gt;</summary>
		<author><name>Ronak</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_15&amp;diff=19091</id>
		<title>DistOS 2014W Lecture 15</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_15&amp;diff=19091"/>
		<updated>2014-04-25T03:54:19Z</updated>

		<summary type="html">&lt;p&gt;Ronak: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Designing Exercise&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Can we do any kind of distributed system without crypto? We can&#039;t trust crypto...&lt;br /&gt;
&lt;br /&gt;
What are the main features we need to consider for such a system ? &lt;br /&gt;
*Limited Sharing&lt;br /&gt;
*Integrity&lt;br /&gt;
*Availability&lt;br /&gt;
&lt;br /&gt;
Perhaps probabilistically...&lt;br /&gt;
&lt;br /&gt;
Want to be able to put data in, have it distributed, and be able to get it out on some other machine. This kind of sharing would need identification or authentication process.&lt;br /&gt;
&lt;br /&gt;
Availability: &amp;quot;distribute the crap out of it&amp;quot;, doesn&#039;t need crypto. No corruption of data. &lt;br /&gt;
&lt;br /&gt;
Integrity: hashing, but we assume hashes can be forged. If we want to know that we got the same file, then simply send each other the file and compare.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Big Takeaway&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Everything you do with crypto is a refinement of what you can already do in&lt;br /&gt;
weaker forms with weaker assumptions.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Note on Project Proposal&#039;&#039;&#039; &lt;br /&gt;
* Date has been extended until next week. As Prof said some of the proposals are not completely up to mark.&lt;br /&gt;
&lt;br /&gt;
===Farsite&lt;br /&gt;
&lt;br /&gt;
This paper describes Farsite, a serverless distributed file system that logically functions as a centralized file server but whose physical realization is dispersed among a network of untrusted desktop workstations.&lt;br /&gt;
An important assumption they mentioned is files are both read by many users and also frequently updated by at least one user which is a disadvantage in Farsite.&lt;br /&gt;
Two technology trends are fundamental in rendering Farsite&#039;s design practical:The large amount of unused disk capacity enables the use of replication for reliability, and the relatively low cost of strong cryptography enables distributed security.&lt;br /&gt;
Every machine in Farsite may perform three roles: It is a client, a member of a directory group, and afile host. A client is a machine that directly interacts with a user. A directory group is a set of machines that collectively manage file information using a Byzantine-fault-tolerant protocol. Every member of the group stores a replica of the information, and as the group receives client requests,&lt;br /&gt;
each member processes these requests deterministically, updates its replica, and sends replies to the client.&lt;br /&gt;
&lt;br /&gt;
When a client wishes to read a file, it sends a message to the directory group, which replies with the&lt;br /&gt;
contents of the requested file.&lt;br /&gt;
Advantage of Farsite are (1)It adds local caching of file content on the client to improve read performance. (2)Farsite delays pushing updates to the directory group, because most file writes are deleted or overwritten shortly after they occur. (3)Performing encryption on a block level enables a client to write an individual block without having to rewrite the entire file. It also enables the client to read individual blocks without having to wait for the download of an entire file from a file host.&lt;/div&gt;</summary>
		<author><name>Ronak</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_15&amp;diff=19090</id>
		<title>DistOS 2014W Lecture 15</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_15&amp;diff=19090"/>
		<updated>2014-04-25T03:53:40Z</updated>

		<summary type="html">&lt;p&gt;Ronak: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Designing Exercise&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Can we do any kind of distributed system without crypto? We can&#039;t trust crypto...&lt;br /&gt;
&lt;br /&gt;
What are the main features we need to consider for such a system ? &lt;br /&gt;
*Limited Sharing&lt;br /&gt;
*Integrity&lt;br /&gt;
*Availability&lt;br /&gt;
&lt;br /&gt;
Perhaps probabilistically...&lt;br /&gt;
&lt;br /&gt;
Want to be able to put data in, have it distributed, and be able to get it out on some other machine. This kind of sharing would need identification or authentication process.&lt;br /&gt;
&lt;br /&gt;
Availability: &amp;quot;distribute the crap out of it&amp;quot;, doesn&#039;t need crypto. No corruption of data. &lt;br /&gt;
&lt;br /&gt;
Integrity: hashing, but we assume hashes can be forged. If we want to know that we got the same file, then simply send each other the file and compare.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Big Takeaway&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Everything you do with crypto is a refinement of what you can already do in&lt;br /&gt;
weaker forms with weaker assumptions.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Note on Project Proposal&#039;&#039;&#039; &lt;br /&gt;
&lt;br /&gt;
This paper describes Farsite, a serverless distributed file system that logically functions as a centralized file server but whose physical realization is dispersed among a network of untrusted desktop workstations.&lt;br /&gt;
An important assumption they mentioned is files are both read by many users and also frequently updated by at least one user which is a disadvantage in Farsite.&lt;br /&gt;
Two technology trends are fundamental in rendering Farsite&#039;s design practical:The large amount of unused disk capacity enables the use of replication for reliability, and the relatively low cost of strong cryptography enables distributed security.&lt;br /&gt;
Every machine in Farsite may perform three roles: It is a client, a member of a directory group, and afile host. A client is a machine that directly interacts with a user. A directory group is a set of machines that collectively manage file information using a Byzantine-fault-tolerant protocol. Every member of the group stores a replica of the information, and as the group receives client requests,&lt;br /&gt;
each member processes these requests deterministically, updates its replica, and sends replies to the client.&lt;br /&gt;
&lt;br /&gt;
When a client wishes to read a file, it sends a message to the directory group, which replies with the&lt;br /&gt;
contents of the requested file.&lt;br /&gt;
Advantage of Farsite are (1)It adds local caching of file content on the client to improve read performance. (2)Farsite delays pushing updates to the directory group, because most file writes are deleted or overwritten shortly after they occur. (3)Performing encryption on a block level enables a client to write an individual block without having to rewrite the entire file. It also enables the client to read individual blocks without having to wait for the download of an entire file from a file host.&lt;br /&gt;
&lt;br /&gt;
* Date has been extended until next week. As Prof said some of the proposals are not completely up to mark.&lt;/div&gt;</summary>
		<author><name>Ronak</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=Distributed_OS:_Winter_2014&amp;diff=18931</id>
		<title>Distributed OS: Winter 2014</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=Distributed_OS:_Winter_2014&amp;diff=18931"/>
		<updated>2014-03-26T21:32:57Z</updated>

		<summary type="html">&lt;p&gt;Ronak: /* Presentations 2 (April 3) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Course Information==&lt;br /&gt;
&lt;br /&gt;
*&#039;&#039;&#039;Course Number:&#039;&#039;&#039; COMP 4000/5102&lt;br /&gt;
*&#039;&#039;&#039;Term:&#039;&#039;&#039; Winter 2014&lt;br /&gt;
*&#039;&#039;&#039;Title:&#039;&#039;&#039; Distributed Operating Systems&lt;br /&gt;
*&#039;&#039;&#039;Institution:&#039;&#039;&#039; Carleton University, School of Computer Science&lt;br /&gt;
*&#039;&#039;&#039;Instructor:&#039;&#039;&#039; [http://people.scs.carleton.ca/~soma Anil Somayaji] (anilsomayaji at connect.carleton.ca): Wed. 3-4 and Thurs. 12-1 in HP 5137&lt;br /&gt;
*&#039;&#039;&#039;Teaching Assistant:&#039;&#039;&#039; Andrew Schoenrock (aschoenr at scs.carleton.ca)&lt;br /&gt;
*&#039;&#039;&#039;Lectures:&#039;&#039;&#039; Tuesday and Thursday 10:05-11:25 AM, ME 3356 &lt;br /&gt;
*&#039;&#039;&#039;Course Website&#039;&#039;&#039;: http://homeostasis.scs.carleton.ca/wiki/index.php?title=Distributed_OS:_Winter_2014&lt;br /&gt;
&lt;br /&gt;
==Official Course Descriptions==&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;COMP 4000:&#039;&#039;&#039; An advanced course emphasizing the principles of distributed operating systems including networking protocols, distributed file systems, remote IPC mechanisms, graphical user interfaces, load balancing, and process migration. Case studies include current &amp;quot;standards&amp;quot; as well as novel systems under development.  Prerequisite(s): one of COMP 3203 or SYSC 4602, and one of COMP 3000, SYSC 3001, SYSC 4001.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;COMP 5102:&#039;&#039;&#039; Design issues of advanced multiprocessor distributed operating systems: multiprocessor system architectures; process and object models; synchronization and message passing primitives; memory architectures and management; distributed file systems; protection and security; distributed concurrency control; deadlock; recovery; remote tasking; dynamic reconfiguration; performance measurement, modeling, and system tuning.  Prerequisite(s): COMP 3000 and COMP 3203 or equivalent.&lt;br /&gt;
&lt;br /&gt;
==Communication==&lt;br /&gt;
&lt;br /&gt;
This wiki page is the canonical source of information on this course.  Please refer to it for updates.  When significant changes are made to this document it will be either announced in lecture and/or posted in the course discussion forum.&lt;br /&gt;
&lt;br /&gt;
Online course discussions will be on [http://culearn.carleton.ca cuLearn].&lt;br /&gt;
&lt;br /&gt;
You should get an account on this wiki so you can edit content here.  Email Prof. Somayaji to get one with your preferred username and email address to which a password should be sent.&lt;br /&gt;
&lt;br /&gt;
==Required Textbooks/Software==&lt;br /&gt;
&lt;br /&gt;
There are no required textbooks or software for this course.  Instead we will be reading research papers which will be linked to from this webpage.  While many of these papers will be available directly via web search, some will be behind paywalls.  In this case there will be alternate links to those pages that go through the Carleton Library&#039;s proxy.&lt;br /&gt;
&lt;br /&gt;
==Grading==&lt;br /&gt;
&lt;br /&gt;
Students enrolled in COMP 4000 (undergraduates) have the following grading scheme:&lt;br /&gt;
&lt;br /&gt;
* 15% Class Participation&lt;br /&gt;
* 15% Reading Responses&lt;br /&gt;
* 10% Lecture Notes/Wiki contributions&lt;br /&gt;
* 25% Midterm (Feb. 27th)&lt;br /&gt;
* 35% Final Exam&lt;br /&gt;
&lt;br /&gt;
Students enrolled in COMP 5102 (mostly graduate students) instead have this grading scheme:&lt;br /&gt;
&lt;br /&gt;
* 15% Class Participation&lt;br /&gt;
* 15% Reading Responses&lt;br /&gt;
* 10% Lecture Notes/Wiki contributions&lt;br /&gt;
* 10% Project Proposal (Feb. 13th - extended!)&lt;br /&gt;
* 15% Project Presentation (April 1st, 3rd)&lt;br /&gt;
* 35% Final Project&lt;br /&gt;
&lt;br /&gt;
Optionally, students enrolled in COMP 4000 may choose to be graded on the COMP 5102 grading scheme.&lt;br /&gt;
&lt;br /&gt;
Each of these elements are explained below.&lt;br /&gt;
&lt;br /&gt;
==Class Participation==&lt;br /&gt;
&lt;br /&gt;
You are expected to attend every class for this course.  Moreover, you are expected to participate in each class.  This participation part of your grade will be based in part upon attendance; however, it will also be based upon the degree to which you were an active participant.  Students who attend every class but who do nothing while in class will get a worse participation grade than those who miss some classes but who fully participate in those they do attend.&lt;br /&gt;
&lt;br /&gt;
==Reading Responses==&lt;br /&gt;
&lt;br /&gt;
* Before the start of class on each Tuesday you should submit an all-text reading response on cuLearn that is approximately 500 words in length.  Responses longer than 600 words may be marked off for verbosity.  Your responses should say what you found interesting and what do you have questions about/were confused by.  Where appropriate, they should also discuss the relationship between the papers of the week and other work that you know about (including those covered earlier in class).&lt;br /&gt;
* &#039;&#039;&#039;Do not summarize the readings.&#039;&#039;&#039; I&#039;ve already read them!  Instead you should be telling me what you got out of these papers, good and bad.  Please also tell me what issues you&#039;d like to learn more about, either in class or potentially through later readings.&lt;br /&gt;
* Responses will be graded on a scale of 0 to 4, with a 4 being given for a response that has clear evidence that you made an effort to read and understand all of the assigned readings.&lt;br /&gt;
* Please submit your responses in plain text or PDF format.  (No MS Word files!  Please convert to PDF or text before submitting.)  You may want to consider writing your response as a text file formatted in [http://en.wikipedia.org/wiki/Markdown Markdown] and then convert the output to PDF using [http://johnmacfarlane.net/pandoc/ pandoc].&lt;br /&gt;
* Responses will be accepted until Thursday, 6 AM.  Responses submitted after Tuesday morning, though, will have a maximum grade of 3, not 4.&lt;br /&gt;
&lt;br /&gt;
==Class Notes/Wiki contributions==&lt;br /&gt;
&lt;br /&gt;
Everyone will be expected to co-author the notes for at least one class and upload them to the class wiki.  Class notes should capture the content of lectures and discussions in a way that will aid study for the midterm and final, especially for those who have missed that particular class.  Draft class notes are due on the wiki a week after the class; however, it is recommended that preliminary notes be uploaded within 48 hours of class.  Notes will need to be revised until they are acceptable; however, students other than the original authors may elect to make modifications and updates.&lt;br /&gt;
&lt;br /&gt;
Wiki contribution grades will be determined based on the overall quality of wiki contributions over the course of the term.&lt;br /&gt;
&lt;br /&gt;
==Midterm and Final Exam==&lt;br /&gt;
&lt;br /&gt;
Undergraduates by default will be required to complete an in-class midterm exam and a formally scheduled final exam.  These will be essay tests based on the material covered in class.  Sample questions will be made available during study sessions prior to the exams.&lt;br /&gt;
&lt;br /&gt;
==Project==&lt;br /&gt;
&lt;br /&gt;
The project may be a literature review of a specialized area of computer science related to distributed operating systems, or it may be a research proposal on a problem related to distributed operating systems.  A research proposal should be thought of as an abbreviated literature review paper combined with a description of potential future work that would fill a gap in the covered literature.&lt;br /&gt;
&lt;br /&gt;
You may choose to follow up on your proposal and actually implement what you propose; given the implementation complexity of most research problems in distributed operating systems, though, such an implementation is strictly optional (but may be advisable if you wish to make your project publishable).&lt;br /&gt;
&lt;br /&gt;
Your project outline should consist of an abstract, an argument outline, and at least ten references that you plan to cite in your final project.&lt;br /&gt;
&lt;br /&gt;
You should run ideas for your project by Prof. Somayaji before writing your proposal before you spent time making your outline.&lt;br /&gt;
&lt;br /&gt;
==Collaboration==&lt;br /&gt;
&lt;br /&gt;
Collaboration on all work is allowed except for the midterm and final exams. Collaboration, however, should be clearly acknowledged.  Specifically, co-authored works should be marked as such.  When co-authored, all authors of reading responses and projects will get the same grade, unless there is reason to believe that some co-authors did not in fact contribute significantly to the submitted work.  Co-authored contributions may get different grades depending upon the relative contribution of the different authors; however, the default here will also be to give all authors the same grade.&lt;br /&gt;
&lt;br /&gt;
It is &#039;&#039;&#039;essential&#039;&#039;&#039; that outside references be cited appropriately.  Proper citation format should be followed except where more relaxed forms are specifically allowed.&lt;br /&gt;
&lt;br /&gt;
Plagiarism or intellectual dishonesty of any kind is strictly forbidden.  In other words, it should always be clear what is your work and what is the work of others.  If anything you submit is, in part or whole, very similar in content or structure to that of work produced by someone else, you are plagiarizing.  This includes figures.&lt;br /&gt;
&lt;br /&gt;
Think of plagiarism as a kind of unauthorized collaboration.  Don&#039;t do it.  Plagiarism and other instructional offenses will be reported to the Dean of Science for disciplinary action, as per university guidelines.&lt;br /&gt;
&lt;br /&gt;
==Topics==&lt;br /&gt;
&lt;br /&gt;
===The Early Internet (Jan. 14)===&lt;br /&gt;
&lt;br /&gt;
* [https://homeostasis.scs.carleton.ca/~soma/distos/2014w/kahn1972-resource.pdf Robert E. Kahn, &amp;quot;Resource-Sharing Computer Communications Networks&amp;quot; (1972)]  [http://dx.doi.org/10.1109/PROC.1972.8911 (DOI)]&lt;br /&gt;
* [https://archive.org/details/ComputerNetworks_TheHeraldsOfResourceSharing Computer Networks: The Heralds of Resource Sharing (1972)] - video&lt;br /&gt;
&lt;br /&gt;
===The Alto (Jan. 16)===&lt;br /&gt;
&lt;br /&gt;
* [https://homeostasis.scs.carleton.ca/~soma/distos/2014w/alto.pdf Thacker et al., &amp;quot;Alto: A Personal computer&amp;quot; (1979)]  ([https://archive.org/details/bitsavers_xeroxparcttoAPersonalComputer_6560658 archive.org])&lt;br /&gt;
&lt;br /&gt;
===The Mother of all Demos (Jan. 21)===&lt;br /&gt;
&lt;br /&gt;
If you can, watch the whole demo.  The Stanford version with annotated clips is good if you are short for time.&lt;br /&gt;
&lt;br /&gt;
* [http://www.dougengelbart.org/firsts/dougs-1968-demo.html Doug Engelbart Institute, &amp;quot;Doug&#039;s 1968 Demo&amp;quot;]&lt;br /&gt;
* [http://en.wikipedia.org/wiki/The_Mother_of_All_Demos Wikipedia&#039;s page on &amp;quot;The Mother of all Demos&amp;quot;]&lt;br /&gt;
&lt;br /&gt;
===The Early Web (Jan. 23)===&lt;br /&gt;
&lt;br /&gt;
* [https://archive.org/details/02Kahle000673 Berners-Lee et al., &amp;quot;World-Wide Web: The Information Universe&amp;quot; (1992)], pp. 52-58&lt;br /&gt;
* [http://www.youtube.com/watch?v=72nfrhXroo8 Alex Wright, &amp;quot;The Web That Wasn&#039;t&amp;quot; (2007)], Google Tech Talk&lt;br /&gt;
&lt;br /&gt;
===UNIX and Plan 9 (Jan. 28)===&lt;br /&gt;
&lt;br /&gt;
* [http://homeostasis.scs.carleton.ca/~soma/distos/fall2008/unix.pdf Dennis M. Ritchie and Ken Thompson, &amp;quot;The UNIX Time-Sharing System&amp;quot; (1974)]&lt;br /&gt;
* [http://homeostasis.scs.carleton.ca/~soma/distos/2014w/presotto-plan9.pdf Presotto et. al, Plan 9, A Distributed System (1991)]&lt;br /&gt;
* [http://homeostasis.scs.carleton.ca/~soma/distos/2014w/pike-plan9.pdf Pike et al., Plan 9 from Bell Labs (1995)]&lt;br /&gt;
&lt;br /&gt;
===NFS and AFS (Jan 30)===&lt;br /&gt;
&lt;br /&gt;
* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/sandberg-nfs.pdf Russel Sandberg et al., &amp;quot;Design and Implementation of the Sun Network Filesystem&amp;quot; (1985)]&lt;br /&gt;
* [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-11/howard-afs.pdf John H. Howard et al., &amp;quot;Scale and Performance in a Distributed File System&amp;quot; (1988)]&lt;br /&gt;
&lt;br /&gt;
===GFS and Ceph (Feb. 4)===&lt;br /&gt;
* [http://research.google.com/archive/gfs-sosp2003.pdf Sanjay Ghemawat et al., &amp;quot;The Google File System&amp;quot; (SOSP 2003)]&lt;br /&gt;
* [http://www.usenix.org/events/osdi06/tech/weil.html Weil et al., Ceph: A Scalable, High-Performance Distributed File System (OSDI 2006)].&lt;br /&gt;
&lt;br /&gt;
===Chubby (Feb. 13)===&lt;br /&gt;
Note: no response this week, as proposals are due on this day.&lt;br /&gt;
* [https://www.usenix.org/legacy/events/osdi06/tech/burrows.html Burrows, The Chubby Lock Service for Loosely-Coupled Distributed Systems (OSDI 2006)]&lt;br /&gt;
&lt;br /&gt;
===Oceanstore (Mar. 4)===&lt;br /&gt;
 &lt;br /&gt;
* [http://homeostasis.scs.carleton.ca/~soma/distos/fall2008/oceanstore-sigplan.pdf John Kubiatowicz et al., &amp;quot;OceanStore: An Architecture for Global-Scale Persistent Storage&amp;quot; (2000)]&lt;br /&gt;
* [http://homeostasis.scs.carleton.ca/~soma/distos/fall2008/fast2003-pond.pdf Sean Rhea et al., &amp;quot;Pond: the OceanStore Prototype&amp;quot; (2003)]&lt;br /&gt;
&lt;br /&gt;
===Farsite (Mar. 6)===&lt;br /&gt;
&lt;br /&gt;
* [http://homeostasis.scs.carleton.ca/~soma/distos/fall2008/adya-farsite-intro.pdf Atul Adya et al.,&amp;quot;FARSITE: Federated, Available, and Reliable Storage for an Incompletely Trusted Environment&amp;quot; (2002)]&lt;br /&gt;
* [http://homeostasis.scs.carleton.ca/~soma/distos/fall2008/bolosky-farsite-retro.pdf William J. Bolosky et al., &amp;quot;The Farsite Project: A Retrospective&amp;quot; (2007)]&lt;br /&gt;
&lt;br /&gt;
===Public Resource Computing (March 11)===&lt;br /&gt;
&lt;br /&gt;
* Anderson et al., &amp;quot;SETI@home: An Experiment in Public-Resource Computing&amp;quot; (CACM 2002) [http://dx.doi.org/10.1145/581571.581573 (DOI)] [http://dl.acm.org.proxy.library.carleton.ca/citation.cfm?id=581573 (Proxy)]&lt;br /&gt;
* Anderson, &amp;quot;BOINC: A System for Public-Resource Computing and Storage&amp;quot; (Grid Computing 2004) [http://dx.doi.org/10.1109/GRID.2004.14 (DOI)] [http://ieeexplore.ieee.org.proxy.library.carleton.ca/stamp/stamp.jsp?tp=&amp;amp;arnumber=1382809 (Proxy)]&lt;br /&gt;
&lt;br /&gt;
===Project Help Session (March 13)===&lt;br /&gt;
&lt;br /&gt;
* Harvey, &amp;quot;What Is a Literature Review?&amp;quot; [http://www.cs.cmu.edu/~missy/WritingaLiteratureReview.doc (DOC)] [http://www.cs.cmu.edu/~missy/Writing_a_Literature_Review.ppt (PPT)]&lt;br /&gt;
* [http://www.writing.utoronto.ca/advice/specific-types-of-writing/literature-review Taylor, &amp;quot;The Literature Review: A Few Tips On Conducting It&amp;quot;]&lt;br /&gt;
&lt;br /&gt;
===Distributed Hash Tables (March 18)===&lt;br /&gt;
&lt;br /&gt;
* [http://en.wikipedia.org/wiki/Distributed_hash_table Wikipedia&#039;s article on Distributed Hash Tables]&lt;br /&gt;
* [http://pdos.csail.mit.edu/~strib/docs/tapestry/tapestry_jsac03.pdf Zhao et al, &amp;quot;Tapestry: A Resilient Global-Scale Overlay for Service Deployment&amp;quot; (JSAC 2003)]&lt;br /&gt;
&lt;br /&gt;
===Structured Data 1 (March 20)===&lt;br /&gt;
&lt;br /&gt;
* [http://research.google.com/archive/bigtable-osdi06.pdf Chang et al., &amp;quot;BigTable: A Distributed Storage System for Structured Data&amp;quot; (OSDI 2006)]&lt;br /&gt;
* [http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf DeCandia et al., &amp;quot;Dynamo: Amazon’s Highly Available Key-value Store&amp;quot; (SOSP 2007)]&lt;br /&gt;
&lt;br /&gt;
===Structured Data 2 (March 25)===&lt;br /&gt;
&lt;br /&gt;
* [http://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf Lakshman &amp;amp; Malik, &amp;quot;Cassandra - A Decentralized Structured Storage System&amp;quot; (LADIS 2009)]&lt;br /&gt;
* [https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Geambasu.pdf Geambasu et al., &amp;quot;Comet: An active distributed key-value store&amp;quot; (OSDI 2010)]&lt;br /&gt;
&lt;br /&gt;
===Computational Models (March 27)===&lt;br /&gt;
&lt;br /&gt;
* [http://research.google.com/archive/mapreduce.html Dean &amp;amp; Ghemawat, &amp;quot;MapReduce: Simplified Data Processing on Large Clusters&amp;quot; (OSDI 2004)]&lt;br /&gt;
* [http://dl.acm.org/citation.cfm?doid=2517349.2522738 Murray et al., &amp;quot;Naiad: a timely dataflow system&amp;quot; (SOSP 2013)]&lt;br /&gt;
&lt;br /&gt;
===Presentations 1 (April 1)===&lt;br /&gt;
&lt;br /&gt;
* Gehana&lt;br /&gt;
* Keerthi&lt;br /&gt;
* Simon &amp;amp; Peter&lt;br /&gt;
* Adam&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
===Presentations 2 (April 3)===&lt;br /&gt;
&lt;br /&gt;
* Mojgan&lt;br /&gt;
* Mohammed&lt;br /&gt;
* Sijo&lt;br /&gt;
* Sandarbh&lt;br /&gt;
* Ronak Chaudhari&lt;br /&gt;
&lt;br /&gt;
===The Future (April 8)===&lt;br /&gt;
&lt;br /&gt;
* [http://dl.acm.org/citation.cfm?id=1562783 Berkeley CS Dept., &amp;quot;A view of the parallel computing landscape&amp;quot; (CACM 2009)]&lt;br /&gt;
* [http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-183.pdf Berkeley CS Dept., &amp;quot;The Landscape of Parallel Computing Research: A View from Berkeley&amp;quot; (2006 Tech Report)]  Note Section 6.2, &amp;quot;Deconstructing operating system support&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
===Grid Computing (Optional)===&lt;br /&gt;
&lt;br /&gt;
* Foster et al., &amp;quot;The Anatomy of the Grid: Enabling Scalable Virtual Organizations&amp;quot; (IJHPCA 2001) [http://dx.doi.org/10.1177/109434200101500302 (DOI)] [http://hpc.sagepub.com.proxy.library.carleton.ca/content/15/3/200 (Library Proxy)]&lt;br /&gt;
* Foster et al., &amp;quot;Cloud Computing and Grid Computing 360-Degree Compared&amp;quot; (GCE 2008) [http://dx.doi.org/10.1109/GCE.2008.4738445 (DOI)] [http://arxiv.org/abs/0901.0131 (arXiv.org)]&lt;br /&gt;
&lt;br /&gt;
==Schedule==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;table style=&amp;quot;width: 100%;&amp;quot; border=&amp;quot;1&amp;quot; cellpadding=&amp;quot;4&amp;quot; cellspacing=&amp;quot;0&amp;quot;&amp;gt;&lt;br /&gt;
  &amp;lt;tr valign=&amp;quot;top&amp;quot;&amp;gt;&lt;br /&gt;
    &amp;lt;th&amp;gt;&lt;br /&gt;
    &amp;lt;p align=&amp;quot;left&amp;quot;&amp;gt;Date&amp;lt;/p&amp;gt;&lt;br /&gt;
    &amp;lt;/th&amp;gt;&lt;br /&gt;
    &amp;lt;th&amp;gt;&lt;br /&gt;
    &amp;lt;p align=&amp;quot;left&amp;quot;&amp;gt;Topic&amp;lt;/p&amp;gt;&lt;br /&gt;
    &amp;lt;/th&amp;gt;&lt;br /&gt;
  &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Jan. 7&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 1|Lecture 1]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Jan. 9&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 2|Lecture 2]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Jan. 14&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 3|Lecture 3]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Jan. 16&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 4|Lecture 4]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Jan. 21&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 5|Lecture 5]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Jan. 23&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 6|Lecture 6]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Jan. 28&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 7|Lecture 7]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Jan. 30&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 8|Lecture 8]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Feb. 4&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 9|Lecture 9]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Feb. 6&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 10|Lecture 10]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Feb. 11&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 11|Lecture 11]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Feb. 13&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 12|Lecture 12]]&amp;lt;br&amp;gt;&#039;&#039;&#039;Project Proposals Due&#039;&#039;&#039;&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Feb. 25&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Midterm Review|Midterm Review]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Feb. 27&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Midterm Exam&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Mar. 4&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 14|Lecture 14]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Mar. 6&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 15|Lecture 15]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Mar. 11&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 16|Lecture 16]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Mar. 13&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 17|Lecture 17]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Mar. 18&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 18|Lecture 18]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Mar. 20&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 19|Lecture 19]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Mar. 25&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 20|Lecture 20]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Mar. 27&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 21|Lecture 21]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Apr. 1&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 22|Lecture 22]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Apr. 3&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 23|Lecture 23]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;Apr. 8&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;[[DistOS 2014W Lecture 24|Lecture 24]]&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
    &amp;lt;tr&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;April 24, 2 PM&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
      &amp;lt;td&amp;gt;&lt;br /&gt;
      &amp;lt;p&amp;gt;&#039;&#039;&#039;Final Exam&#039;&#039;&#039;&lt;br /&gt;
      &amp;lt;/p&amp;gt;&lt;br /&gt;
      &amp;lt;/td&amp;gt;&lt;br /&gt;
    &amp;lt;/tr&amp;gt;&lt;br /&gt;
&amp;lt;/table&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==University Policies==&lt;br /&gt;
&lt;br /&gt;
===Student Academic Integrity Policy===&lt;br /&gt;
&lt;br /&gt;
Every student should be familiar with the Carleton University student academic integrity policy. A student found in violation of academic integrity standards may be awarded penalties which range from a reprimand to receiving a grade of F in the course or even being expelled from the program or University. Some examples of offences are: plagiarism and unauthorized co-operation or collaboration. Information on this policy may be found in the Undergraduate Calendar.&lt;br /&gt;
&lt;br /&gt;
===Plagiarism===&lt;br /&gt;
&lt;br /&gt;
As defined by Senate, &amp;quot;plagiarism is presenting, whether intentional or not, the ideas, expression of ideas or work of others as one&#039;s own&amp;quot;. Such reported offences will be reviewed by the office of the Dean of Science.&lt;br /&gt;
&lt;br /&gt;
===Unauthorized Co-operation or Collaboration===&lt;br /&gt;
&lt;br /&gt;
Senate policy states that &amp;quot;to ensure fairness and equity in assessment of term work, students shall not co-operate or collaborate in the completion of an academic assignment, in whole or in part, when the instructor has indicated that the assignment is to be completed on an individual basis&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
Please see above for the specific collaboration policy for this course.&lt;br /&gt;
&lt;br /&gt;
===Academic Accommodations for Students with Disabilities===&lt;br /&gt;
&lt;br /&gt;
The Paul Menton Centre for Students with Disabilities (PMC) provides services to students with Learning Disabilities (LD), psychiatric/mental health disabilities, Attention Deficit Hyperactivity Disorder (ADHD), Autism Spectrum Disorders (ASD), chronic medical conditions, and impairments in mobility, hearing, and vision. If you have a disability requiring academic accommodations in this course, please contact PMC at 613-520-6608 or pmc@carleton.ca for a formal evaluation. If you are already registered with the PMC, contact your PMC coordinator to send me your Letter of Accommodation at the beginning of the term, and no later than two weeks before the first in-class scheduled test or exam requiring accommodation (if applicable). After requesting accommodation from PMC, meet with me to ensure accommodation arrangements are made. Please consult the PMC website for the deadline to request accommodations for the formally-scheduled exam (if applicable) at http://www2.carleton.ca/pmc/new-and-current-students/dates-and-deadlines&lt;br /&gt;
&lt;br /&gt;
===Religious Obligation===&lt;br /&gt;
&lt;br /&gt;
Write to the instructor with any requests for academic accommodation during the first two weeks of class, or as soon as possible after the need for accommodation is known to exist. For more details visit the Equity Services website: http://www2.carleton.ca/equity/&lt;br /&gt;
&lt;br /&gt;
===Pregnancy Obligation===&lt;br /&gt;
&lt;br /&gt;
Write to the instructor with any requests for academic accommodation during the first two weeks of class, or as soon as possible after the need for accommodation is known to exist. For more details visit the Equity Services website: http://www2.carleton.ca/equity/&lt;br /&gt;
&lt;br /&gt;
===Medical Certificate===&lt;br /&gt;
&lt;br /&gt;
The following is a link to the official medical certificate accepted by Carleton University for the deferral of final examinations or assignments in undergraduate courses. To access the form, please go to http://www.carleton.ca/registrar/forms&lt;/div&gt;</summary>
		<author><name>Ronak</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_20&amp;diff=18927</id>
		<title>DistOS 2014W Lecture 20</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_20&amp;diff=18927"/>
		<updated>2014-03-25T18:51:54Z</updated>

		<summary type="html">&lt;p&gt;Ronak: /* Comet */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Cassandra ==&lt;br /&gt;
&lt;br /&gt;
Cassandra is essentially running a BigTable interface on top of a Dynamo infrastructure.  BigTable uses GFS&#039; built-in replication and Chubby for locking.  Cassandra uses gossip algorithms: [http://dl.acm.org/citation.cfm?id=1529983 Scuttlebutt].  &lt;br /&gt;
&lt;br /&gt;
Initialy Anil talked about google versus facebook approach to technologies.Google developed its technology internally and used for competitive advantage.Facebook developed its technology in open source manner.He talked little bit about licences. Gpl 3 you have to provide code with binary. In AGPL additional service also be given with source code.&lt;br /&gt;
&lt;br /&gt;
While discussing Hbase versus Cassandra discussed why two projects with same notion are supported?Apache as a community. For any tool in CS particularly software tools, its actually important to have more than one good implementation. Only time it doesn&#039;t happen because of market realities. &lt;br /&gt;
&lt;br /&gt;
Bigtable and Cassandra exposes similar apis. Bigtable needs GFS. Cassandra depends on server&#039;s file system.Anil feels cassandra cluster is easy to setup. Bigtable is designed for batch updates.Cassandra is for handling realtime stuff.&lt;br /&gt;
	&lt;br /&gt;
Schema design is explained in inbox example.It does not give clarity about how table will look like. Anil thinks they store lot data with messages which makes table crappy.&lt;br /&gt;
	&lt;br /&gt;
Cassandra is design for high speed access and online operation.&lt;br /&gt;
	&lt;br /&gt;
Apache Zookeeper is used for distributed configuration. Zookeeper is similar to chubby. Zookeeper is for node level information.Gossip is more about key partitioning.Zookeeper is for configuration of new node.&lt;br /&gt;
&lt;br /&gt;
Cassandra uses a modified version of the Accrual Failure Detector. The idea of an Accrual Failure Detection is that failure detection module emits a value which represents a suspicion level for each of monitored nodes. The idea is to express the value of phi� on a scale that is dynamically adjusted to react network and load conditions at the monitored nodes.&lt;br /&gt;
&lt;br /&gt;
Cassandra writes in immutable way like functional programming.There is no assignment in functional programming. It tries to eliminate side effects. Data is just binded you associate a name with a value. Garbage collection.&lt;br /&gt;
&lt;br /&gt;
Casandra - &lt;br /&gt;
GFS type cluster which big table depends on &lt;br /&gt;
Lighter weight &lt;br /&gt;
All most of the readings are part of Apache&lt;br /&gt;
More designed for online updates for interactive lower latency &lt;br /&gt;
Once they write to disk they only read back&lt;br /&gt;
Scalable multi master database with no single point of failure&lt;br /&gt;
Reason for not giving out the complete detail on the table schema&lt;br /&gt;
Probably not just inbox search&lt;br /&gt;
All data in one row of a table &lt;br /&gt;
Its not a key-value store. Big blob of data. &lt;br /&gt;
Gossip based protocol - Scuttlebutt&lt;br /&gt;
Fixed circular ring &lt;br /&gt;
Consistency issue not addressed at all. Does writes in an immutable way. Never change them. &lt;br /&gt;
&lt;br /&gt;
Older style network protocol - token rings&lt;br /&gt;
What sort of computational systems avoid changing data?&lt;br /&gt;
Systems talking about implementing functional like semantics.&lt;br /&gt;
&lt;br /&gt;
== Comet ==&lt;br /&gt;
&lt;br /&gt;
The major idea behind Comet is triggers/callbacks.  There is an extensive literature in extensible operating systems, basically adding code to the operating system to better suit my application.  &amp;quot;Generally, extensible systems suck.&amp;quot; -[[User:Soma]]&lt;br /&gt;
&lt;br /&gt;
[https://www.usenix.org/conference/osdi10/comet-active-distributed-key-value-store The presentation video of Comet]&lt;br /&gt;
&lt;br /&gt;
Comet seeks to greatly expand the application space for key-value storage systems through application-specific customization.Comet storage object is a &amp;lt;key,value&amp;gt; pair.Each Comet node stores a collection of active storage objects (ASOs) that consist of a key, a value, and a set of handlers. Comet handlers run as a result of timers or storage operations, such as get or put, allowing an ASO to take dynamic, application-specific actions to customize its behaviour. Handlers are written in a simple sandboxed extension language, providing properties of safety and isolation.ASO can modify its environment, monitor its execution,and make dynamic decisions about its state.&lt;br /&gt;
&lt;br /&gt;
Researchers try to provide the ability to extend a DHT without requiring a substantial investment of effort to modify its implementation.They try to implement to isolation and safety using restricting system access,restricting resource consumption and restricting within-Comet communication.&lt;/div&gt;</summary>
		<author><name>Ronak</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_20&amp;diff=18923</id>
		<title>DistOS 2014W Lecture 20</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_20&amp;diff=18923"/>
		<updated>2014-03-25T16:50:15Z</updated>

		<summary type="html">&lt;p&gt;Ronak: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Cassandra ==&lt;br /&gt;
&lt;br /&gt;
Cassandra is essentially running a BigTable interface on top of a Dynamo infrastructure.  BigTable uses GFS&#039; built-in replication and Chubby for locking.  Cassandra uses gossip algorithms: [http://dl.acm.org/citation.cfm?id=1529983 Scuttlebutt].  &lt;br /&gt;
&lt;br /&gt;
Initialy Anil talked about google versus facebook approach to technologies.Google developed its technology internally and used for competitive advantage.Facebook developed its technology in open source manner.He talked little bit about licences. Gpl 3 you have to provide code with binary.In AGPL additional service also be given with source code.&lt;br /&gt;
&lt;br /&gt;
While discussing Hbase versus Cassandra discussed why two projects with same notion are supported?Apache as a community. For any tool in CS particularly software tools, its actually important to have more than one good implementation. Only time it doesn&#039;t happen because of market realities. &lt;br /&gt;
&lt;br /&gt;
Bigtable and Cassandra exposes similar apis.Bigtable needs GFS.Cassandra depends on server&#039;s file system.Anil feels cassandra cluster is easy to setup.Bigtable is designed for batch updates.Cassandra is for handling realtime stuff.&lt;br /&gt;
	&lt;br /&gt;
Schema design is explained in inbox example.It does not give clarity about how table will look like.Anil thinks they store lot data with messages which makes table crappy.&lt;br /&gt;
	&lt;br /&gt;
Cassandra is design for high speed access and online operation.&lt;br /&gt;
	&lt;br /&gt;
Apache Zookeeper is used for distributed configuration.Zookeeper is similar to chhuby. Zookeeper is for node level information.Gossip is more about key partitioning.Zookeeper is for configuration of new node.&lt;br /&gt;
&lt;br /&gt;
Cassandra uses a modified version of the Accrual Failure Detector. The idea of an Accrual Failure Detection is that failure detection module emits a value which represents a suspicion level for each of monitored nodes. The idea is to express the value of phi� on a scale that is dynamically adjusted to react network and load conditions at the monitored nodes.&lt;br /&gt;
&lt;br /&gt;
Cassandra writes in immutable way like functional programming.There is no assignment in functional programming.It tries to eliminate side effects.Data is just binded you associate a name with a value. Garbage collection.&lt;br /&gt;
&lt;br /&gt;
Casandra - &lt;br /&gt;
GFS type cluster which big table depends on &lt;br /&gt;
Lighter weight &lt;br /&gt;
All most of the readings are part of Apache&lt;br /&gt;
More designed for online updates for interactive lower latency &lt;br /&gt;
Once they write to disk they only read back&lt;br /&gt;
Scalable multi master database with no single point of failure&lt;br /&gt;
Reason for not giving out the complete detail on the table schema&lt;br /&gt;
Probably not just inbox search&lt;br /&gt;
All data in one row of a table &lt;br /&gt;
Its not a key-value store. Big blob of data. &lt;br /&gt;
Gossip based protocol - Scufflebutt&lt;br /&gt;
Fixed circular ring &lt;br /&gt;
Consistency issue not addressed at all. Does writes in an immutable way. Never change them. &lt;br /&gt;
&lt;br /&gt;
Older style network protocol - token rings&lt;br /&gt;
What sort of computational systems avoid changing data?&lt;br /&gt;
Systems talking about implementing functional like semantics.&lt;br /&gt;
&lt;br /&gt;
== Comet ==&lt;br /&gt;
&lt;br /&gt;
The major idea behind Comet is triggers/callbacks.  There is an extensive literature in extensible operating systems, basically adding code to the operating system to better suit my application.  &amp;quot;Generally, extensible systems suck.&amp;quot; -[[User:Soma]]&lt;br /&gt;
&lt;br /&gt;
[https://www.usenix.org/conference/osdi10/comet-active-distributed-key-value-store The presentation video of Comet]&lt;br /&gt;
&lt;br /&gt;
Comet seeks to greatly expand the application space for key-value storage systems through application-specific customization.Each Comet node stores a collection of active storage objects (ASOs) that consist of a key, a value, and a set of handlers. Comet handlers run as a result of timers or storage operations, such as get or put, allowing an ASO to take dynamic, application-specific actions to customize its behaviour. Handlers are written in a simple sandboxed extension language, providing properties of safety and isolation.&lt;/div&gt;</summary>
		<author><name>Ronak</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_20&amp;diff=18922</id>
		<title>DistOS 2014W Lecture 20</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_20&amp;diff=18922"/>
		<updated>2014-03-25T16:45:02Z</updated>

		<summary type="html">&lt;p&gt;Ronak: /* Comet */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Cassandra ==&lt;br /&gt;
&lt;br /&gt;
Cassandra is essentially running a BigTable interface on top of a Dynamo infrastructure.  BigTable uses GFS&#039; built-in replication and Chubby for locking.  Cassandra uses gossip algorithms: [http://dl.acm.org/citation.cfm?id=1529983 Scuttlebutt].  &lt;br /&gt;
&lt;br /&gt;
Initialy Anil talked about google versus facebook approach to technologies.Google developed its technology internally and used for competitive advantage.Facebook developed its technology in open source manner.He talked little bit about licences. Gpl 3 you have to provide code with binary.In AGPL additional service also be given with source code.&lt;br /&gt;
&lt;br /&gt;
While discussing Hbase versus Cassandra discussed why two projects with same notion are supported?Apache as a community. For any tool in CS particularly software tools, its actually important to have more than one good implementation. Only time it doesn&#039;t happen because of market realities. &lt;br /&gt;
&lt;br /&gt;
Bigtable needs GFS.cassandra depends on server&#039;s file system.Anil feels cassandra cluster is easy to setup.Bigtable is designed for batch updates.Cassandra is for handling realtime stuff.&lt;br /&gt;
	&lt;br /&gt;
Schema design is explained in inbox example.It does not give clarity about how table will look like.Anil thinks they store lot data with messages which makes table crappy.&lt;br /&gt;
	&lt;br /&gt;
Cassandra is design for high speed access and online operation.&lt;br /&gt;
	&lt;br /&gt;
Apache Zookeeper is used for distributed configuration.Zookeeper is similar to chhuby. Zookeeper is for node level information.Gossip is more about key partitioning.Zookeeper is for configuration of new node.&lt;br /&gt;
&lt;br /&gt;
Cassandra writes in immutable way like functional programming.There is no assignment in functional programming.It tries to eliminate side effects.Data is just binded you associate a name with a value. Garbage collection.&lt;br /&gt;
&lt;br /&gt;
Casandra - &lt;br /&gt;
GFS type cluster which big table depends on &lt;br /&gt;
Lighter weight &lt;br /&gt;
All most of the readings are part of Apache&lt;br /&gt;
More designed for online updates for interactive lower latency &lt;br /&gt;
Once they write to disk they only read back&lt;br /&gt;
Scalable multi master database with no single point of failure&lt;br /&gt;
Reason for not giving out the complete detail on the table schema&lt;br /&gt;
Probably not just inbox search&lt;br /&gt;
All data in one row of a table &lt;br /&gt;
Its not a key-value store. Big blob of data. &lt;br /&gt;
Gossip based protocol - Scufflebutt&lt;br /&gt;
Fixed circular ring &lt;br /&gt;
Consistency issue not addressed at all. Does writes in an immutable way. Never change them. &lt;br /&gt;
&lt;br /&gt;
Older style network protocol - token rings&lt;br /&gt;
What sort of computational systems avoid changing data?&lt;br /&gt;
Systems talking about implementing functional like semantics.&lt;br /&gt;
&lt;br /&gt;
== Comet ==&lt;br /&gt;
&lt;br /&gt;
The major idea behind Comet is triggers/callbacks.  There is an extensive literature in extensible operating systems, basically adding code to the operating system to better suit my application.  &amp;quot;Generally, extensible systems suck.&amp;quot; -[[User:Soma]]&lt;br /&gt;
&lt;br /&gt;
[https://www.usenix.org/conference/osdi10/comet-active-distributed-key-value-store The presentation video of Comet]&lt;br /&gt;
&lt;br /&gt;
Comet seeks to greatly expand the application space for key-value storage systems through application-specific customization.Each Comet node stores a collection of active storage objects (ASOs) that consist of a key, a value, and a set of handlers. Comet handlers run as a result of timers or storage operations, such as get or put, allowing an ASO to take dynamic, application-specific actions to customize its behaviour. Handlers are written in a simple sandboxed extension language, providing properties of safety and isolation.&lt;/div&gt;</summary>
		<author><name>Ronak</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_20&amp;diff=18921</id>
		<title>DistOS 2014W Lecture 20</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_20&amp;diff=18921"/>
		<updated>2014-03-25T16:40:08Z</updated>

		<summary type="html">&lt;p&gt;Ronak: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Cassandra ==&lt;br /&gt;
&lt;br /&gt;
Cassandra is essentially running a BigTable interface on top of a Dynamo infrastructure.  BigTable uses GFS&#039; built-in replication and Chubby for locking.  Cassandra uses gossip algorithms: [http://dl.acm.org/citation.cfm?id=1529983 Scuttlebutt].  &lt;br /&gt;
&lt;br /&gt;
Initialy Anil talked about google versus facebook approach to technologies.Google developed its technology internally and used for competitive advantage.Facebook developed its technology in open source manner.He talked little bit about licences. Gpl 3 you have to provide code with binary.In AGPL additional service also be given with source code.&lt;br /&gt;
&lt;br /&gt;
While discussing Hbase versus Cassandra discussed why two projects with same notion are supported?Apache as a community. For any tool in CS particularly software tools, its actually important to have more than one good implementation. Only time it doesn&#039;t happen because of market realities. &lt;br /&gt;
&lt;br /&gt;
Bigtable needs GFS.cassandra depends on server&#039;s file system.Anil feels cassandra cluster is easy to setup.Bigtable is designed for batch updates.Cassandra is for handling realtime stuff.&lt;br /&gt;
	&lt;br /&gt;
Schema design is explained in inbox example.It does not give clarity about how table will look like.Anil thinks they store lot data with messages which makes table crappy.&lt;br /&gt;
	&lt;br /&gt;
Cassandra is design for high speed access and online operation.&lt;br /&gt;
	&lt;br /&gt;
Apache Zookeeper is used for distributed configuration.Zookeeper is similar to chhuby. Zookeeper is for node level information.Gossip is more about key partitioning.Zookeeper is for configuration of new node.&lt;br /&gt;
&lt;br /&gt;
Cassandra writes in immutable way like functional programming.There is no assignment in functional programming.It tries to eliminate side effects.Data is just binded you associate a name with a value. Garbage collection.&lt;br /&gt;
&lt;br /&gt;
Casandra - &lt;br /&gt;
GFS type cluster which big table depends on &lt;br /&gt;
Lighter weight &lt;br /&gt;
All most of the readings are part of Apache&lt;br /&gt;
More designed for online updates for interactive lower latency &lt;br /&gt;
Once they write to disk they only read back&lt;br /&gt;
Scalable multi master database with no single point of failure&lt;br /&gt;
Reason for not giving out the complete detail on the table schema&lt;br /&gt;
Probably not just inbox search&lt;br /&gt;
All data in one row of a table &lt;br /&gt;
Its not a key-value store. Big blob of data. &lt;br /&gt;
Gossip based protocol - Scufflebutt&lt;br /&gt;
Fixed circular ring &lt;br /&gt;
Consistency issue not addressed at all. Does writes in an immutable way. Never change them. &lt;br /&gt;
&lt;br /&gt;
Older style network protocol - token rings&lt;br /&gt;
What sort of computational systems avoid changing data?&lt;br /&gt;
Systems talking about implementing functional like semantics.&lt;br /&gt;
&lt;br /&gt;
== Comet ==&lt;br /&gt;
&lt;br /&gt;
The major idea behind Comet is triggers/callbacks.  There is an extensive literature in extensible operating systems, basically adding code to the operating system to better suit my application.  &amp;quot;Generally, extensible systems suck.&amp;quot; -[[User:Soma]]&lt;br /&gt;
&lt;br /&gt;
[https://www.usenix.org/conference/osdi10/comet-active-distributed-key-value-store The presentation video of Comet]&lt;/div&gt;</summary>
		<author><name>Ronak</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_20&amp;diff=18920</id>
		<title>DistOS 2014W Lecture 20</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_20&amp;diff=18920"/>
		<updated>2014-03-25T16:38:19Z</updated>

		<summary type="html">&lt;p&gt;Ronak: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Cassandra ==&lt;br /&gt;
&lt;br /&gt;
Cassandra is essentially running a BigTable interface on top of a Dynamo infrastructure.  BigTable uses GFS&#039; built-in replication and Chubby for locking.  Cassandra uses gossip algorithms: [http://dl.acm.org/citation.cfm?id=1529983 Scuttlebutt].  &lt;br /&gt;
&lt;br /&gt;
Initialy Anil talked about google versus facebook approach to technologies.Google developed its technology internally and used for competitive advantage.Facebook developed its technology in open source manner.He talked little bit about licences. Gpl 3 you have to provide code with binary In AGPL additional service also be given with source code.&lt;br /&gt;
&lt;br /&gt;
While discussing Hbase versus Cassandra dsicussed why two projects with same notion are supported?Apache as a community. For any tool in CS particularly software tools, its actually important to have more than one good implementation. Only time it doesn&#039;t happen because of market realities. &lt;br /&gt;
&lt;br /&gt;
Bigtable needs GFS.cassandra depends on server&#039;s file system.Anil feels cassandra cluster is easy to setup.Bigtable is designed for batch updates.Cassandra is for handling realtime stuff.&lt;br /&gt;
	&lt;br /&gt;
Schema design is explained in inbox example.It does does not give clarity about how table will look like.Anil thinks they store lot data with messages which makes table crappy.&lt;br /&gt;
	&lt;br /&gt;
Cassandra is design for high speed access and online operation.&lt;br /&gt;
	&lt;br /&gt;
Apache Zookeeper is used for distributed configuration.Zookeeper is similar to chhuby. Zookeeper is for node level information.Gossip is more about key partitioning.Zookeeper is for configuration of new node.&lt;br /&gt;
&lt;br /&gt;
Cassandra writes in immutable way like functional programming.There is no assignment in functional programming.It tries to eliminate side effects.Data is just binded you associate a name with a value. Garbage collection.&lt;br /&gt;
&lt;br /&gt;
Casandra - &lt;br /&gt;
GFS type cluster which big table depends on &lt;br /&gt;
Lighter weight &lt;br /&gt;
All most of the readings are part of Apache&lt;br /&gt;
More designed for online updates for interactive lower latency &lt;br /&gt;
Once they write to disk they only read back&lt;br /&gt;
Scalable multi master database with no single point of failure&lt;br /&gt;
Reason for not giving out the complete detail on the table schema&lt;br /&gt;
Probably not just inbox search&lt;br /&gt;
All data in one row of a table &lt;br /&gt;
Its not a key-value store. Big blob of data. &lt;br /&gt;
Gossip based protocol - Scufflebutt&lt;br /&gt;
Fixed circular ring &lt;br /&gt;
Consistency issue not addressed at all. Does writes in an immutable way. Never change them. &lt;br /&gt;
&lt;br /&gt;
Older style network protocol - token rings&lt;br /&gt;
What sort of computational systems avoid changing data?&lt;br /&gt;
Systems talking about implementing functional like semantics.&lt;br /&gt;
&lt;br /&gt;
== Comet ==&lt;br /&gt;
&lt;br /&gt;
The major idea behind Comet is triggers/callbacks.  There is an extensive literature in extensible operating systems, basically adding code to the operating system to better suit my application.  &amp;quot;Generally, extensible systems suck.&amp;quot; -[[User:Soma]]&lt;br /&gt;
&lt;br /&gt;
[https://www.usenix.org/conference/osdi10/comet-active-distributed-key-value-store The presentation video of Comet]&lt;/div&gt;</summary>
		<author><name>Ronak</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_20&amp;diff=18919</id>
		<title>DistOS 2014W Lecture 20</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_20&amp;diff=18919"/>
		<updated>2014-03-25T16:37:48Z</updated>

		<summary type="html">&lt;p&gt;Ronak: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Cassandra ==&lt;br /&gt;
&lt;br /&gt;
Cassandra is essentially running a BigTable interface on top of a Dynamo infrastructure.  BigTable uses GFS&#039; built-in replication and Chubby for locking.  Cassandra uses gossip algorithms: [http://dl.acm.org/citation.cfm?id=1529983 Scuttlebutt].  Apache Zookeeper is used for distributed configuration.&lt;br /&gt;
&lt;br /&gt;
Initialy Anil talked about google versus facebook approach to technologies.Google developed its technology internally and used for competitive advantage.Facebook developed its technology in open source manner.He talked little bit about licences. Gpl 3 you have to provide code with binary In AGPL additional service also be given with source code.&lt;br /&gt;
&lt;br /&gt;
While discussing Hbase versus Cassandra dsicussed why two projects with same notion are supported?Apache as a community. For any tool in CS particularly software tools, its actually important to have more than one good implementation. Only time it doesn&#039;t happen because of market realities. &lt;br /&gt;
&lt;br /&gt;
Bigtable needs GFS.cassandra depends on server&#039;s file system.Anil feels cassandra cluster is easy to setup.Bigtable is designed for batch updates.Cassandra is for handling realtime stuff.&lt;br /&gt;
	&lt;br /&gt;
Schema design is explained in inbox example.It does does not give clarity about how table will look like.Anil thinks they store lot data with messages which makes table crappy.&lt;br /&gt;
	&lt;br /&gt;
Cassandra is design for high speed access and online operation.&lt;br /&gt;
	&lt;br /&gt;
Zookeeper is similar to chhuby. Zookeeper is for node level information.Gossip is more about key partitioning.Zookeeper is for configuration of new node.&lt;br /&gt;
&lt;br /&gt;
Cassandra writes in immutable way like functional programming.There is no assignment in functional programming.It tries to eliminate side effects.Data is just binded you associate a name with a value. Garbage collection.&lt;br /&gt;
&lt;br /&gt;
Casandra - &lt;br /&gt;
GFS type cluster which big table depends on &lt;br /&gt;
Lighter weight &lt;br /&gt;
All most of the readings are part of Apache&lt;br /&gt;
More designed for online updates for interactive lower latency &lt;br /&gt;
Once they write to disk they only read back&lt;br /&gt;
Scalable multi master database with no single point of failure&lt;br /&gt;
Reason for not giving out the complete detail on the table schema&lt;br /&gt;
Probably not just inbox search&lt;br /&gt;
All data in one row of a table &lt;br /&gt;
Its not a key-value store. Big blob of data. &lt;br /&gt;
Gossip based protocol - Scufflebutt&lt;br /&gt;
Fixed circular ring &lt;br /&gt;
Consistency issue not addressed at all. Does writes in an immutable way. Never change them. &lt;br /&gt;
&lt;br /&gt;
Older style network protocol - token rings&lt;br /&gt;
What sort of computational systems avoid changing data?&lt;br /&gt;
Systems talking about implementing functional like semantics.&lt;br /&gt;
&lt;br /&gt;
== Comet ==&lt;br /&gt;
&lt;br /&gt;
The major idea behind Comet is triggers/callbacks.  There is an extensive literature in extensible operating systems, basically adding code to the operating system to better suit my application.  &amp;quot;Generally, extensible systems suck.&amp;quot; -[[User:Soma]]&lt;br /&gt;
&lt;br /&gt;
[https://www.usenix.org/conference/osdi10/comet-active-distributed-key-value-store The presentation video of Comet]&lt;/div&gt;</summary>
		<author><name>Ronak</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_20&amp;diff=18918</id>
		<title>DistOS 2014W Lecture 20</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_20&amp;diff=18918"/>
		<updated>2014-03-25T16:29:52Z</updated>

		<summary type="html">&lt;p&gt;Ronak: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Cassandra ==&lt;br /&gt;
&lt;br /&gt;
Cassandra is essentially running a BigTable interface on top of a Dynamo infrastructure.  BigTable uses GFS&#039; built-in replication and Chubby for locking.  Cassandra uses gossip algorithms: [http://dl.acm.org/citation.cfm?id=1529983 Scuttlebutt].  Apache Zookeeper is used for distributed configuration.&lt;br /&gt;
&lt;br /&gt;
Initialy Anil talked about google versus facebook approach to technologies.Google developed its technology internally and used for competitive advantage.Facebook developed its technology in open source manner.He talked little bit about licences.Gpl 3 you have to provide code with binary&lt;br /&gt;
In AGPL additional service also be given with source code.&lt;br /&gt;
&lt;br /&gt;
Bigtable needs GFS.cassandra depends on server&#039;s file system.Anil feels cassndra cluster is easy to setup.Bigtable is designed for batch updates.Cassandra is for handling realtime stuff.&lt;br /&gt;
	&lt;br /&gt;
Schema design is explained in inbox example.It does does not give clarity about how table will look like.Anil thinks they store lot data with messages which makes table crappy.&lt;br /&gt;
	&lt;br /&gt;
Cassandra is design for high speed access and online operation.&lt;br /&gt;
	&lt;br /&gt;
Zookeeper is similar to chhuby. Zookeeper is for node level information.Gossip is more about key partitioning.Zookeeper is for configuration of new node.&lt;br /&gt;
&lt;br /&gt;
Cassandra writes in immutable way like functional programming.There is no assignment in functional programming.&lt;br /&gt;
&lt;br /&gt;
Casandra - &lt;br /&gt;
GFS type cluster which big table depends on &lt;br /&gt;
Lighter weight &lt;br /&gt;
All most of the readings are part of Apache&lt;br /&gt;
More designed for online updates for interactive lower latency &lt;br /&gt;
Once they write to disk they only read back&lt;br /&gt;
Scalable multi master database with no single point of failure&lt;br /&gt;
Reason for not giving out the complete detail on the table schema&lt;br /&gt;
Probably not just inbox search&lt;br /&gt;
All data in one row of a table &lt;br /&gt;
Its not a key-value store. Big blob of data. &lt;br /&gt;
Gossip based protocol - Scufflebutt&lt;br /&gt;
Fixed circular ring &lt;br /&gt;
Consistency issue not addressed at all. Does writes in an immutable way. Never change them. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Cassandra&lt;br /&gt;
	&lt;br /&gt;
Cassandra is essentially running a BigTable interface on top of a Dynamo infrastructure.  BigTable uses GFS&#039; built-in replication and Chubby for locking.  Cassandra uses gossip algorithms: [http://dl.acm.org/citation.cfm?id=1529983 Scuttlebutt].  Apache Zookeeper is used for distributed configuration.&lt;br /&gt;
 		 	&lt;br /&gt;
Discussions&lt;br /&gt;
&lt;br /&gt;
Athero GPL&lt;br /&gt;
Cassandra vs Big table&lt;br /&gt;
BigTable is not part of Hadoop. &lt;br /&gt;
BigTable &amp;quot; Funny thing on top of GFS&amp;quot;&lt;br /&gt;
History of HDFS&lt;br /&gt;
Hbase&lt;br /&gt;
Why two projects with same notion are supported?&lt;br /&gt;
Apache as a community. For any tool in CS particularly software tools, its actually important to have more &lt;br /&gt;
&lt;br /&gt;
than one good implementation. Only time it doesnt happen because of market realities. &lt;br /&gt;
Older style network protocol - token rings&lt;br /&gt;
What sort of computational systems avoid changing data? &lt;br /&gt;
Functional programming languages - &lt;br /&gt;
Whats different from classic c and c++. Tries to eliminate side effects. Functional there is no assignment.Data is just binded you associate a name with a value. Garbage collection. No mutation of data. &lt;br /&gt;
Systems talking about implementing functional like semantics.&lt;br /&gt;
&lt;br /&gt;
== Comet ==&lt;br /&gt;
&lt;br /&gt;
The major idea behind Comet is triggers/callbacks.  There is an extensive literature in extensible operating systems, basically adding code to the operating system to better suit my application.  &amp;quot;Generally, extensible systems suck.&amp;quot; -[[User:Soma]]&lt;br /&gt;
&lt;br /&gt;
[https://www.usenix.org/conference/osdi10/comet-active-distributed-key-value-store The presentation video of Comet]&lt;/div&gt;</summary>
		<author><name>Ronak</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_20&amp;diff=18917</id>
		<title>DistOS 2014W Lecture 20</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_20&amp;diff=18917"/>
		<updated>2014-03-25T15:46:01Z</updated>

		<summary type="html">&lt;p&gt;Ronak: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Cassandra ==&lt;br /&gt;
&lt;br /&gt;
Cassandra is essentially running a BigTable interface on top of a Dynamo infrastructure.  BigTable uses GFS&#039; built-in replication and Chubby for locking.  Cassandra uses gossip algorithms: [http://dl.acm.org/citation.cfm?id=1529983 Scuttlebutt].  Apache Zookeeper is used for distributed configuration.&lt;br /&gt;
&lt;br /&gt;
Casandra - &lt;br /&gt;
GFS type cluster which big table depends on &lt;br /&gt;
Lighter weight &lt;br /&gt;
All most of the readings are part of Apache&lt;br /&gt;
More designed for online updates for interactive lower latency &lt;br /&gt;
Once they write to disk they only read back&lt;br /&gt;
Scalable multi master database with no single point of failure&lt;br /&gt;
Reason for not giving out the complete detail on the table schema&lt;br /&gt;
Probably not just inbox search&lt;br /&gt;
All data in one row of a table &lt;br /&gt;
Its not a key-value store. Big blob of data. &lt;br /&gt;
Gossip based protocol - Scufflebutt&lt;br /&gt;
Fixed circular ring &lt;br /&gt;
Consistency issue not addressed at all. Does writes in an immutable way. Never change them. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Cassandra&lt;br /&gt;
	&lt;br /&gt;
Cassandra is essentially running a BigTable interface on top of a Dynamo infrastructure.  BigTable uses GFS&#039; built-in replication and Chubby for locking.  Cassandra uses gossip algorithms: [http://dl.acm.org/citation.cfm?id=1529983 Scuttlebutt].  Apache Zookeeper is used for distributed configuration.&lt;br /&gt;
 		 	&lt;br /&gt;
	&lt;br /&gt;
Google developed its technology internally and used for competitive advantage.&lt;br /&gt;
Facebook developed its technology in open source manner.&lt;br /&gt;
Gpl 3 you have to provide code with binary&lt;br /&gt;
In AGPL addtional service also be given with source code.&lt;br /&gt;
	&lt;br /&gt;
Bigtable needs gfs.cassandra depends on server&#039;s file system.Anil feels cassndra cluster is easy to setup.&lt;br /&gt;
	&lt;br /&gt;
Bigtable is designed for batch updates.cassandra is for hqbdling realtime stuff.&lt;br /&gt;
	&lt;br /&gt;
Schema design is explained in inbox example.it does does not give clarity about how table will look like.Anil thinks they store lot data with messages which makes table crappy.&lt;br /&gt;
	&lt;br /&gt;
Cassandra is design for high speed access and online operation.&lt;br /&gt;
	&lt;br /&gt;
Zookeeper is similar to chhuby&lt;br /&gt;
	&lt;br /&gt;
Zookeeper is for node level information&lt;br /&gt;
	&lt;br /&gt;
Gossip is more about key partitioning&lt;br /&gt;
	&lt;br /&gt;
Zookeeper is for configuration of new node.&lt;br /&gt;
&lt;br /&gt;
It writes in immutable way like functional programming.there is no assignment in functional programming.&lt;br /&gt;
&lt;br /&gt;
Discussions&lt;br /&gt;
&lt;br /&gt;
Athero GPL&lt;br /&gt;
Cassandra vs Big table&lt;br /&gt;
BigTable is not part of Hadoop. &lt;br /&gt;
BigTable &amp;quot; Funny thing on top of GFS&amp;quot;&lt;br /&gt;
History of HDFS&lt;br /&gt;
Hbase&lt;br /&gt;
Why two projects with same notion are supported?&lt;br /&gt;
Apache as a community. For any tool in CS particularly software tools, its actually important to have more &lt;br /&gt;
&lt;br /&gt;
than one good implementation. Only time it doesnt happen because of market realities. &lt;br /&gt;
Older style network protocol - token rings&lt;br /&gt;
What sort of computational systems avoid changing data? &lt;br /&gt;
Functional programming languages - &lt;br /&gt;
Whats different from classic c and c++. Tries to eliminate side effects. Functional there is no assignment.Data is just binded you associate a name with a value. Garbage collection. No mutation of data. &lt;br /&gt;
Systems talking about implementing functional like semantics.&lt;br /&gt;
&lt;br /&gt;
== Comet ==&lt;br /&gt;
&lt;br /&gt;
The major idea behind Comet is triggers/callbacks.  There is an extensive literature in extensible operating systems, basically adding code to the operating system to better suit my application.  &amp;quot;Generally, extensible systems suck.&amp;quot; -[[User:Soma]]&lt;br /&gt;
&lt;br /&gt;
[https://www.usenix.org/conference/osdi10/comet-active-distributed-key-value-store The presentation video of Comet]&lt;/div&gt;</summary>
		<author><name>Ronak</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_20&amp;diff=18914</id>
		<title>DistOS 2014W Lecture 20</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=DistOS_2014W_Lecture_20&amp;diff=18914"/>
		<updated>2014-03-25T15:24:35Z</updated>

		<summary type="html">&lt;p&gt;Ronak: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
== Cassandra ==&lt;br /&gt;
&lt;br /&gt;
Cassandra is essentially running a BigTable interface on top of a Dynamo infrastructure.  BigTable uses GFS&#039; built-in replication and Chubby for locking.  Cassandra uses gossip algorithms: [http://dl.acm.org/citation.cfm?id=1529983 Scuttlebutt].  Apache Zookeeper is used for distributed configuration.&lt;br /&gt;
&lt;br /&gt;
== Comet ==&lt;br /&gt;
&lt;br /&gt;
The major idea behind Comet is triggers/callbacks.  There is an extensive literature in extensible operating systems, basically adding code to the operating system to better suit my application.&lt;br /&gt;
&lt;br /&gt;
[https://www.usenix.org/conference/osdi10/comet-active-distributed-key-value-store The presentation video of Comet]&lt;br /&gt;
&lt;br /&gt;
Cassandra&lt;br /&gt;
+	&lt;br /&gt;
Cassandra is essentially running a BigTable interface on top of a Dynamo infrastructure.  BigTable uses GFS&#039; built-in replication and Chubby for locking.  Cassandra uses gossip algorithms: [http://dl.acm.org/citation.cfm?id=1529983 Scuttlebutt].  Apache Zookeeper is used for distributed configuration.&lt;br /&gt;
 		 	&lt;br /&gt;
−	&lt;br /&gt;
Google developed its technology interbally and used for competitive advantage.&lt;br /&gt;
+	&lt;br /&gt;
== Comet ==&lt;br /&gt;
−	&lt;br /&gt;
Facebook developed its technology in open source manner.&lt;br /&gt;
+	&lt;br /&gt;
 		 	&lt;br /&gt;
−	&lt;br /&gt;
Gpl 3 you have to provide code with binary&lt;br /&gt;
+	&lt;br /&gt;
[https://www.usenix.org/conference/osdi10/comet-active-distributed-key-value-store The presentation video of Comet]&lt;br /&gt;
−	&lt;br /&gt;
In AGPL addtional service also be given with source code.&lt;br /&gt;
+	&lt;br /&gt;
−	&lt;br /&gt;
 &lt;br /&gt;
+	&lt;br /&gt;
−	&lt;br /&gt;
Bigtable needs gfs.cassandra depends on server&#039;s file system.Anil feels cassndra cluster is easy to setup.&lt;br /&gt;
+	&lt;br /&gt;
−	&lt;br /&gt;
 &lt;br /&gt;
+	&lt;br /&gt;
−	&lt;br /&gt;
Bigtable is designed for batch updates.cassandra is for hqbdling realtime stuff.&lt;br /&gt;
+	&lt;br /&gt;
−	&lt;br /&gt;
 &lt;br /&gt;
+	&lt;br /&gt;
−	&lt;br /&gt;
Schema design is explained in inbox example.it does does not give clarity about how table will look like.Anil thinks they store lot data with messages which makes table crappy.&lt;br /&gt;
+	&lt;br /&gt;
−	&lt;br /&gt;
 &lt;br /&gt;
+	&lt;br /&gt;
−	&lt;br /&gt;
Cassandra is design for high speed access and online operation.&lt;br /&gt;
+	&lt;br /&gt;
−	&lt;br /&gt;
 &lt;br /&gt;
+	&lt;br /&gt;
−	&lt;br /&gt;
Zookeeper is similar to chhuby&lt;br /&gt;
+	&lt;br /&gt;
−	&lt;br /&gt;
Zookeeper is for node level information&lt;br /&gt;
+	&lt;br /&gt;
−	&lt;br /&gt;
Gossip is more about key partitioning&lt;br /&gt;
+	&lt;br /&gt;
−	&lt;br /&gt;
 &lt;br /&gt;
+	&lt;br /&gt;
−	&lt;br /&gt;
Zookeeper is for configuration of new node.&lt;br /&gt;
+	&lt;br /&gt;
−	&lt;br /&gt;
 &lt;br /&gt;
+	&lt;br /&gt;
−	&lt;br /&gt;
It writes in immutable way like functional programming.there is no assignment in functional programming.&lt;/div&gt;</summary>
		<author><name>Ronak</name></author>
	</entry>
</feed>