Soma-notes - User contributions [en]

DistOS 2014W Lecture 3

2014-03-14T21:14:21Z

Gbooth: /* Group 4 */

==The Early Internet (Jan. 14)==

* [https://homeostasis.scs.carleton.ca/~soma/distos/2014w/kahn1972-resource.pdf Robert E. Kahn, "Resource-Sharing Computer Communications Networks" (1972)] [http://dx.doi.org/10.1109/PROC.1972.8911 (DOI)]
* [https://archive.org/details/ComputerNetworks_TheHeraldsOfResourceSharing Computer Networks: The Heralds of Resource Sharing (1972)] - video

== Questions to consider: ==
# What were the purposes envisioned for computer networks? How do those compare with the uses they are put to today?
# What sort of resources were shared? What resources are shared today?
# What network architecture did they envision? Do we still have the same architecture?
# What surprised you about this paper?
# What was unclear?

==Group 1==
=== Discussion ===
The video was mostly a summary of Kahn's paper. It was outlined that process mitigation could be done through different zones of air traffic control. Back then, a "distributed OS" meant something different than we normally think about it now. This is because, when the paper was written, many people would be remotely logging onto a single machine. This type of infrastructure is very much like the cloud infrastructure that we see talk about and see today.

The Alto paper referenced Kahn's paper, and the Alto designers had the foresight to see that networks such as ARPANET would be necessary. However, there are still some questions that come up in discussion, such as:
* Would it be useful to have a co-processor responsible for maintaining shared resources even today? Would this be like the IMPs of ARPANET?
Today, computers are usually so fast that it doesn't really seem to matter. This is still interesting to ruminate on, though.

=== Questions ===

'''What were the purposes envisioned for computer networks?'''

The main purposes envisioned were:
* Big computation
* Storage
* Resource sharing
Essentially, being able to "have a library on a hard disk".

'''How do those compare with the uses they are put to today?'''

Today, those things/goals are being done, but we are mostly seeing communication-based things such as instant messaging and email.

'''What sort of resources were shared?'''

The main resources being shared were databases and CPU time.

'''What resources are shared today?'''

Storage is the main resource being shared today.

'''What network architecture did they envision? '''

The network architecture would make use of pack-switching. There would be a checksum and acknowledge on each packet and the IMPs were the network interface, and the routers.

'''Do we still have the same architecture?'''

Although, packet-switching definitely won, we do not have the same architecture now as the IP doesn't have a checksum or acknowledge. But TCP does have an end-to-end checksum and acknowledge. Kahn went on to learn fro the errors of ARPANET to design TCP/IP. Also, the job of the network interface and router have now been decoupled.

'''What surprised you about this paper?'''

Everything was surprising about this paper. How were they able to dl all of this? A network interface card and router were the size of a fridge! Some general things of note:
* High-level languages
* Bootstrapping protocols, bootstrapping applications
* Primitive computers
* Desktop publishing
* The logistics of running a cable from one university to another
* How old the idea of distributed operating system is

'''What was unclear?'''
Much of the more technical specifications were unclear, but we mostly skipped over those

==Group 2==

'''What were the purposes envisioned for computer networks? How do those compare with the uses they are put to today?'''

The main purpose of early networks was resource sharing. Abstractions were used for transmission and message reliability was a by-product. The underlying idea is the same.

Specialized Hardware/software and information sharing. super set of sharing.

The AD-HOC routing was essentially TCP without saying it. Largely unchanged today.

'''What sort of resources were shared? What resources are shared today?'''

''' What network architecture did they envision? Do we still have the same architecture?'''

''' What surprised you about this paper?'''

''' What was unclear?'''

==Group 3==

'''What were the purposes envisioned for computer networks? How do those compare with the uses they are put to today?'''

The purposes envisioned for computer networks were:
* Improving reliability of services, due to redundant resource sets
* Resource sharing
* Usage modes:t
** Users can use a remote terminal, from a remote office or home, to access those resources.
** Would allow centralization of resources, to improve ease of management and do away with inefficiencies
* Allow specialization of various sites. rather than each site trying to do it all
* Distributed simulations (notably air traffic control)

Information-sharing is still relevant today, especially in research and large simulations. Remote access has mostly devolved into a specialized need.

'''What sort of resources were shared? What resources are shared today?'''

The main resources being shared were computing resources (especially expensive mainframes) and data sets.

''' What network architecture did they envision? Do we still have the same architecture?'''

They envisioned a primitive layered architecture with dedicated routing functions. Some of the various topologies were:
* star
* loop
* bus

It was also primarily (packet | message)-switched. Circuit-switching was too expensive and had large setup times and this didn't require committing resources. There was also primitive flow control and buffering.

This network architecture predated proper congestion control, such as Van Jacobsen's slow start. The routing was either Ad-hoc or based on something similar to RIP. They would anticipate elephants and have mice latency issues. Unlike the modern internet, there was error control and retransmission at every step.

The architecture today is similar, but the link-layer is very different: use of Ethernet and ATM. The modern internet is a collection of autonomous systems, not a single network. Routing propagation is now large-scale, and semi-automated (e.g., BGP externally, IS-IS and OSPF internally)

''' What surprised you about this paper?'''

''' What was unclear?'''

The weird packet format: Page 1400 (4 of PDF): “Node 6, discovering the message is for itself, replaces the destination address by the source address"

==Group 4==

'''What were the purposes envisioned for computer networks? How do those compare with the uses they are put to today?'''

Networks were envisioned as providing remote access to other computers, because useful resources such as computing power, large databases, and non-portable software were local to a particular computer, not themselves shared over the network.

Today, we use networks mostly for sharing data, although with services like Amazon AWS, we're starting to share computing resources again. We're also moving to support collaboration (e.g. Google Docs, GitHub, etc.).

'''What sort of resources were shared? What resources are shared today?'''

Computing power was the key resource being shared; today, it's access to data. (See above.)

'''What network architecture did they envision? Do we still have the same architecture?'''

Surprisingly, yes: modern networks have substantially similar architectures to the ones described in these papers.

Packet-switched networks are now ubiquitous. We no longer bother with circuit-switching even for telephony, in contrast to the assumption that non-network data would continue to use the circuit-switched common-carrier network.

'''What surprised you about this paper?'''

We were surprised by the accuracy of the predictions given how early the paper was written — even things like electronic banking. Also surprising were technological advances since the paper was written, such as data transfer speeds (we have networks that are faster than the integrated bus in the Alto), and the predicted resolution requirements (which we are nowhere near meeting). The amount of detail in the description of the 'mouse pointing device' was interesting too.

'''What was unclear? '''

Nothing significant; we're looking at these with the benefit of hindsight.

==Summary of the discussion from lecture==
Anil's view is that even these days we can imagine Computer Networks as more of a resource sharing platform. For example when we access the web or search Google we are making use of the resource sharing facilitated by the Internet(Network of interconnected Computer Networks). It's not possible to put 20,000 computers in our basements’, instead the Internet facilitates access to computing power/databases which are built of hundred thousands of computers. In fact Google and other popular search engines has a local copy of the entire web in their data centers, centralized copy of a large distributed system. Kind of a contradictory phenomenon if you think about in terms of the design goals of the distributed system.

Another important takeaway from the discussion was the point that "Early to market/ first player" with a new product/solution to a niche problem and the one which offer solutions based on simple mechanisms as opposed to one relying on complex mechanism gets adopted faster. Classic example is the Internet. ARPANET which was supposed to be an academic research project which was based on simple mechanisms, open and first of its kind got adopted widely and evolved in to the Internet as we see it today. It is to note that this approach is not without its own drawbacks example being the security aspects were not factored in while designing the ARPANET since it was intended to be a network between trusted parties, which was fine then. But when ARPANET evolved in to the Internet, security aspect was one area which required a major focus on. In Silicon Valley the focus is on being the "first player" in a niche market to meet that objective often simple framework/mechanisms are used. In doing so there is also a possibility of leaving out some components which can turn out to be a vital missing link, recent example being security flaw in 'snapchat' that lead to user data being exposed.

DistOS 2014W Lecture 3

2014-03-14T21:13:31Z

Gbooth: /* Group 3 */

==The Early Internet (Jan. 14)==

* [https://homeostasis.scs.carleton.ca/~soma/distos/2014w/kahn1972-resource.pdf Robert E. Kahn, "Resource-Sharing Computer Communications Networks" (1972)] [http://dx.doi.org/10.1109/PROC.1972.8911 (DOI)]
* [https://archive.org/details/ComputerNetworks_TheHeraldsOfResourceSharing Computer Networks: The Heralds of Resource Sharing (1972)] - video

== Questions to consider: ==
# What were the purposes envisioned for computer networks? How do those compare with the uses they are put to today?
# What sort of resources were shared? What resources are shared today?
# What network architecture did they envision? Do we still have the same architecture?
# What surprised you about this paper?
# What was unclear?

==Group 1==
=== Discussion ===
The video was mostly a summary of Kahn's paper. It was outlined that process mitigation could be done through different zones of air traffic control. Back then, a "distributed OS" meant something different than we normally think about it now. This is because, when the paper was written, many people would be remotely logging onto a single machine. This type of infrastructure is very much like the cloud infrastructure that we see talk about and see today.

The Alto paper referenced Kahn's paper, and the Alto designers had the foresight to see that networks such as ARPANET would be necessary. However, there are still some questions that come up in discussion, such as:
* Would it be useful to have a co-processor responsible for maintaining shared resources even today? Would this be like the IMPs of ARPANET?
Today, computers are usually so fast that it doesn't really seem to matter. This is still interesting to ruminate on, though.

=== Questions ===

'''What were the purposes envisioned for computer networks?'''

The main purposes envisioned were:
* Big computation
* Storage
* Resource sharing
Essentially, being able to "have a library on a hard disk".

'''How do those compare with the uses they are put to today?'''

Today, those things/goals are being done, but we are mostly seeing communication-based things such as instant messaging and email.

'''What sort of resources were shared?'''

The main resources being shared were databases and CPU time.

'''What resources are shared today?'''

Storage is the main resource being shared today.

'''What network architecture did they envision? '''

The network architecture would make use of pack-switching. There would be a checksum and acknowledge on each packet and the IMPs were the network interface, and the routers.

'''Do we still have the same architecture?'''

Although, packet-switching definitely won, we do not have the same architecture now as the IP doesn't have a checksum or acknowledge. But TCP does have an end-to-end checksum and acknowledge. Kahn went on to learn fro the errors of ARPANET to design TCP/IP. Also, the job of the network interface and router have now been decoupled.

'''What surprised you about this paper?'''

Everything was surprising about this paper. How were they able to dl all of this? A network interface card and router were the size of a fridge! Some general things of note:
* High-level languages
* Bootstrapping protocols, bootstrapping applications
* Primitive computers
* Desktop publishing
* The logistics of running a cable from one university to another
* How old the idea of distributed operating system is

'''What was unclear?'''
Much of the more technical specifications were unclear, but we mostly skipped over those

==Group 2==

'''What were the purposes envisioned for computer networks? How do those compare with the uses they are put to today?'''

The main purpose of early networks was resource sharing. Abstractions were used for transmission and message reliability was a by-product. The underlying idea is the same.

Specialized Hardware/software and information sharing. super set of sharing.

The AD-HOC routing was essentially TCP without saying it. Largely unchanged today.

'''What sort of resources were shared? What resources are shared today?'''

''' What network architecture did they envision? Do we still have the same architecture?'''

''' What surprised you about this paper?'''

''' What was unclear?'''

==Group 3==

'''What were the purposes envisioned for computer networks? How do those compare with the uses they are put to today?'''

The purposes envisioned for computer networks were:
* Improving reliability of services, due to redundant resource sets
* Resource sharing
* Usage modes:t
** Users can use a remote terminal, from a remote office or home, to access those resources.
** Would allow centralization of resources, to improve ease of management and do away with inefficiencies
* Allow specialization of various sites. rather than each site trying to do it all
* Distributed simulations (notably air traffic control)

Information-sharing is still relevant today, especially in research and large simulations. Remote access has mostly devolved into a specialized need.

'''What sort of resources were shared? What resources are shared today?'''

The main resources being shared were computing resources (especially expensive mainframes) and data sets.

''' What network architecture did they envision? Do we still have the same architecture?'''

They envisioned a primitive layered architecture with dedicated routing functions. Some of the various topologies were:
* star
* loop
* bus

It was also primarily (packet | message)-switched. Circuit-switching was too expensive and had large setup times and this didn't require committing resources. There was also primitive flow control and buffering.

This network architecture predated proper congestion control, such as Van Jacobsen's slow start. The routing was either Ad-hoc or based on something similar to RIP. They would anticipate elephants and have mice latency issues. Unlike the modern internet, there was error control and retransmission at every step.

The architecture today is similar, but the link-layer is very different: use of Ethernet and ATM. The modern internet is a collection of autonomous systems, not a single network. Routing propagation is now large-scale, and semi-automated (e.g., BGP externally, IS-IS and OSPF internally)

''' What surprised you about this paper?'''

''' What was unclear?'''

The weird packet format: Page 1400 (4 of PDF): “Node 6, discovering the message is for itself, replaces the destination address by the source address"

==Group 4==

* What were the purposes envisioned for computer networks? How do those compare with the uses they are put to today?

Networks were envisioned as providing remote access to other computers, because useful resources such as computing power, large databases, and non-portable software were local to a particular computer, not themselves shared over the network.

Today, we use networks mostly for sharing data, although with services like Amazon AWS, we're starting to share computing resources again. We're also moving to support collaboration (e.g. Google Docs, GitHub, etc.).

* What sort of resources were shared? What resources are shared today?

Computing power was the key resource being shared; today, it's access to data. (See above.)

* What network architecture did they envision? Do we still have the same architecture?

Surprisingly, yes: modern networks have substantially similar architecures to the ones described in these papers.
Packet-switched networks are now ubiquitous. We no longer bother with circuit-switching even for telephony, in contrast to the assumption that non-network data would continue to use the circuit-switched common-carrier network.

* What surprised you about this paper?

We were surprised by the accuracy of the predictions given how early the paper was written — even things like electronic banking. Also surprising were technological advances since the paper was written, such as data transfer speeds (we have networks that are faster than the integrated bus in the Alto), and the predicted resolution requirements (which we are nowhere near meeting). The amount of detail in the description of the 'mouse pointing device' was interesting too.

* What was unclear?

Nothing significant; we're looking at these with the benefit of hindsight.

==Summary of the discussion from lecture==
Anil's view is that even these days we can imagine Computer Networks as more of a resource sharing platform. For example when we access the web or search Google we are making use of the resource sharing facilitated by the Internet(Network of interconnected Computer Networks). It's not possible to put 20,000 computers in our basements’, instead the Internet facilitates access to computing power/databases which are built of hundred thousands of computers. In fact Google and other popular search engines has a local copy of the entire web in their data centers, centralized copy of a large distributed system. Kind of a contradictory phenomenon if you think about in terms of the design goals of the distributed system.

Another important takeaway from the discussion was the point that "Early to market/ first player" with a new product/solution to a niche problem and the one which offer solutions based on simple mechanisms as opposed to one relying on complex mechanism gets adopted faster. Classic example is the Internet. ARPANET which was supposed to be an academic research project which was based on simple mechanisms, open and first of its kind got adopted widely and evolved in to the Internet as we see it today. It is to note that this approach is not without its own drawbacks example being the security aspects were not factored in while designing the ARPANET since it was intended to be a network between trusted parties, which was fine then. But when ARPANET evolved in to the Internet, security aspect was one area which required a major focus on. In Silicon Valley the focus is on being the "first player" in a niche market to meet that objective often simple framework/mechanisms are used. In doing so there is also a possibility of leaving out some components which can turn out to be a vital missing link, recent example being security flaw in 'snapchat' that lead to user data being exposed.

DistOS 2014W Lecture 3

2014-03-14T21:06:13Z

Gbooth: /* Group 2 */

==The Early Internet (Jan. 14)==

* [https://homeostasis.scs.carleton.ca/~soma/distos/2014w/kahn1972-resource.pdf Robert E. Kahn, "Resource-Sharing Computer Communications Networks" (1972)] [http://dx.doi.org/10.1109/PROC.1972.8911 (DOI)]
* [https://archive.org/details/ComputerNetworks_TheHeraldsOfResourceSharing Computer Networks: The Heralds of Resource Sharing (1972)] - video

== Questions to consider: ==
# What were the purposes envisioned for computer networks? How do those compare with the uses they are put to today?
# What sort of resources were shared? What resources are shared today?
# What network architecture did they envision? Do we still have the same architecture?
# What surprised you about this paper?
# What was unclear?

==Group 1==
=== Discussion ===
The video was mostly a summary of Kahn's paper. It was outlined that process mitigation could be done through different zones of air traffic control. Back then, a "distributed OS" meant something different than we normally think about it now. This is because, when the paper was written, many people would be remotely logging onto a single machine. This type of infrastructure is very much like the cloud infrastructure that we see talk about and see today.

The Alto paper referenced Kahn's paper, and the Alto designers had the foresight to see that networks such as ARPANET would be necessary. However, there are still some questions that come up in discussion, such as:
* Would it be useful to have a co-processor responsible for maintaining shared resources even today? Would this be like the IMPs of ARPANET?
Today, computers are usually so fast that it doesn't really seem to matter. This is still interesting to ruminate on, though.

=== Questions ===

'''What were the purposes envisioned for computer networks?'''

The main purposes envisioned were:
* Big computation
* Storage
* Resource sharing
Essentially, being able to "have a library on a hard disk".

'''How do those compare with the uses they are put to today?'''

Today, those things/goals are being done, but we are mostly seeing communication-based things such as instant messaging and email.

'''What sort of resources were shared?'''

The main resources being shared were databases and CPU time.

'''What resources are shared today?'''

Storage is the main resource being shared today.

'''What network architecture did they envision? '''

The network architecture would make use of pack-switching. There would be a checksum and acknowledge on each packet and the IMPs were the network interface, and the routers.

'''Do we still have the same architecture?'''

Although, packet-switching definitely won, we do not have the same architecture now as the IP doesn't have a checksum or acknowledge. But TCP does have an end-to-end checksum and acknowledge. Kahn went on to learn fro the errors of ARPANET to design TCP/IP. Also, the job of the network interface and router have now been decoupled.

'''What surprised you about this paper?'''

Everything was surprising about this paper. How were they able to dl all of this? A network interface card and router were the size of a fridge! Some general things of note:
* High-level languages
* Bootstrapping protocols, bootstrapping applications
* Primitive computers
* Desktop publishing
* The logistics of running a cable from one university to another
* How old the idea of distributed operating system is

'''What was unclear?'''
Much of the more technical specifications were unclear, but we mostly skipped over those

==Group 2==

'''What were the purposes envisioned for computer networks? How do those compare with the uses they are put to today?'''

The main purpose of early networks was resource sharing. Abstractions were used for transmission and message reliability was a by-product. The underlying idea is the same.

Specialized Hardware/software and information sharing. super set of sharing.

The AD-HOC routing was essentially TCP without saying it. Largely unchanged today.

'''What sort of resources were shared? What resources are shared today?'''

''' What network architecture did they envision? Do we still have the same architecture?'''

''' What surprised you about this paper?'''

''' What was unclear?'''

==Group 3==
===Envisioned computer network purposes===
* Improving reliability of services, due to redundant resource sets
* Resource sharing
* Usage modes:t
** Users can use a remote terminal, from a remote office or home, to access those resources.
** Would allow centralization of resources, to improve ease of management and do away with inefficiencies
* Allow specialization of various sites. rather than each site trying to do it all
* Distributed simulations (notably air traffic control)

Information-sharing is still relevant today, especially in research and large simulations. Remote access has mostly devolved into a specialized need.

===Resources shared===
* Computing resources (especially expensive mainframes)
* Data sets

===Network architecture===
* A primitive layered architecture
* Dedicated routing functions
* Various topologies:
** star
** loop
** bus
* Primarily (packet|mesage)-switched
** Circuit-switching too expensive and has large setup times
** Doesn't require committing resources
* Primitive flow control and buffering
* Predates proper congestion control such as Van Jacobsen's slow start
* Ad-hoc routing or based on something similar to RIP
* Anticipation of elephants and mice latency issues
* Unlike modern internet, error control and retransmission at every step

The architecture today is similar, but the link-layer is very different: use of Ethernet and ATM. The modern internet is a collection of autonomous systems, not a single network. Routing propogation is now large-scale, and semi-automated (e.g., BGP externally, IS-IS and OSPF internally)

===Surprising aspects===

===Unclear portions===
* Weird packet format: Page 1400 (4 of PDF): “Node 6, discovering the message is for itself,
replaces the destination address by the source address

==Group 4==

* What were the purposes envisioned for computer networks? How do those compare with the uses they are put to today?

Networks were envisioned as providing remote access to other computers, because useful resources such as computing power, large databases, and non-portable software were local to a particular computer, not themselves shared over the network.

Today, we use networks mostly for sharing data, although with services like Amazon AWS, we're starting to share computing resources again. We're also moving to support collaboration (e.g. Google Docs, GitHub, etc.).

* What sort of resources were shared? What resources are shared today?

Computing power was the key resource being shared; today, it's access to data. (See above.)

* What network architecture did they envision? Do we still have the same architecture?

Surprisingly, yes: modern networks have substantially similar architecures to the ones described in these papers.
Packet-switched networks are now ubiquitous. We no longer bother with circuit-switching even for telephony, in contrast to the assumption that non-network data would continue to use the circuit-switched common-carrier network.

* What surprised you about this paper?

We were surprised by the accuracy of the predictions given how early the paper was written — even things like electronic banking. Also surprising were technological advances since the paper was written, such as data transfer speeds (we have networks that are faster than the integrated bus in the Alto), and the predicted resolution requirements (which we are nowhere near meeting). The amount of detail in the description of the 'mouse pointing device' was interesting too.

* What was unclear?

Nothing significant; we're looking at these with the benefit of hindsight.

==Summary of the discussion from lecture==
Anil's view is that even these days we can imagine Computer Networks as more of a resource sharing platform. For example when we access the web or search Google we are making use of the resource sharing facilitated by the Internet(Network of interconnected Computer Networks). It's not possible to put 20,000 computers in our basements’, instead the Internet facilitates access to computing power/databases which are built of hundred thousands of computers. In fact Google and other popular search engines has a local copy of the entire web in their data centers, centralized copy of a large distributed system. Kind of a contradictory phenomenon if you think about in terms of the design goals of the distributed system.

Another important takeaway from the discussion was the point that "Early to market/ first player" with a new product/solution to a niche problem and the one which offer solutions based on simple mechanisms as opposed to one relying on complex mechanism gets adopted faster. Classic example is the Internet. ARPANET which was supposed to be an academic research project which was based on simple mechanisms, open and first of its kind got adopted widely and evolved in to the Internet as we see it today. It is to note that this approach is not without its own drawbacks example being the security aspects were not factored in while designing the ARPANET since it was intended to be a network between trusted parties, which was fine then. But when ARPANET evolved in to the Internet, security aspect was one area which required a major focus on. In Silicon Valley the focus is on being the "first player" in a niche market to meet that objective often simple framework/mechanisms are used. In doing so there is also a possibility of leaving out some components which can turn out to be a vital missing link, recent example being security flaw in 'snapchat' that lead to user data being exposed.

DistOS 2014W Lecture 3

2014-03-14T21:01:54Z

Gbooth: /* Questions */

==The Early Internet (Jan. 14)==

* [https://homeostasis.scs.carleton.ca/~soma/distos/2014w/kahn1972-resource.pdf Robert E. Kahn, "Resource-Sharing Computer Communications Networks" (1972)] [http://dx.doi.org/10.1109/PROC.1972.8911 (DOI)]
* [https://archive.org/details/ComputerNetworks_TheHeraldsOfResourceSharing Computer Networks: The Heralds of Resource Sharing (1972)] - video

== Questions to consider: ==
# What were the purposes envisioned for computer networks? How do those compare with the uses they are put to today?
# What sort of resources were shared? What resources are shared today?
# What network architecture did they envision? Do we still have the same architecture?
# What surprised you about this paper?
# What was unclear?

==Group 1==
=== Discussion ===
The video was mostly a summary of Kahn's paper. It was outlined that process mitigation could be done through different zones of air traffic control. Back then, a "distributed OS" meant something different than we normally think about it now. This is because, when the paper was written, many people would be remotely logging onto a single machine. This type of infrastructure is very much like the cloud infrastructure that we see talk about and see today.

The Alto paper referenced Kahn's paper, and the Alto designers had the foresight to see that networks such as ARPANET would be necessary. However, there are still some questions that come up in discussion, such as:
* Would it be useful to have a co-processor responsible for maintaining shared resources even today? Would this be like the IMPs of ARPANET?
Today, computers are usually so fast that it doesn't really seem to matter. This is still interesting to ruminate on, though.

=== Questions ===

'''What were the purposes envisioned for computer networks?'''

The main purposes envisioned were:
* Big computation
* Storage
* Resource sharing
Essentially, being able to "have a library on a hard disk".

'''How do those compare with the uses they are put to today?'''

Today, those things/goals are being done, but we are mostly seeing communication-based things such as instant messaging and email.

'''What sort of resources were shared?'''

The main resources being shared were databases and CPU time.

'''What resources are shared today?'''

Storage is the main resource being shared today.

'''What network architecture did they envision? '''

The network architecture would make use of pack-switching. There would be a checksum and acknowledge on each packet and the IMPs were the network interface, and the routers.

'''Do we still have the same architecture?'''

Although, packet-switching definitely won, we do not have the same architecture now as the IP doesn't have a checksum or acknowledge. But TCP does have an end-to-end checksum and acknowledge. Kahn went on to learn fro the errors of ARPANET to design TCP/IP. Also, the job of the network interface and router have now been decoupled.

'''What surprised you about this paper?'''

Everything was surprising about this paper. How were they able to dl all of this? A network interface card and router were the size of a fridge! Some general things of note:
* High-level languages
* Bootstrapping protocols, bootstrapping applications
* Primitive computers
* Desktop publishing
* The logistics of running a cable from one university to another
* How old the idea of distributed operating system is

'''What was unclear?'''
Much of the more technical specifications were unclear, but we mostly skipped over those

==Group 2==
1. The main purpose of early networks was resource sharing. Abstraction for transmission. Message reliability was a by-product. The underlying idea is the same.

2. Specialized Hardware/software and information sharing. super set of sharing.

3. AD-HOC routing, it was TCP without saying it. Largely unchanged today.

==Group 3==
===Envisioned computer network purposes===
* Improving reliability of services, due to redundant resource sets
* Resource sharing
* Usage modes:t
** Users can use a remote terminal, from a remote office or home, to access those resources.
** Would allow centralization of resources, to improve ease of management and do away with inefficiencies
* Allow specialization of various sites. rather than each site trying to do it all
* Distributed simulations (notably air traffic control)

Information-sharing is still relevant today, especially in research and large simulations. Remote access has mostly devolved into a specialized need.

===Resources shared===
* Computing resources (especially expensive mainframes)
* Data sets

===Network architecture===
* A primitive layered architecture
* Dedicated routing functions
* Various topologies:
** star
** loop
** bus
* Primarily (packet|mesage)-switched
** Circuit-switching too expensive and has large setup times
** Doesn't require committing resources
* Primitive flow control and buffering
* Predates proper congestion control such as Van Jacobsen's slow start
* Ad-hoc routing or based on something similar to RIP
* Anticipation of elephants and mice latency issues
* Unlike modern internet, error control and retransmission at every step

The architecture today is similar, but the link-layer is very different: use of Ethernet and ATM. The modern internet is a collection of autonomous systems, not a single network. Routing propogation is now large-scale, and semi-automated (e.g., BGP externally, IS-IS and OSPF internally)

===Surprising aspects===

===Unclear portions===
* Weird packet format: Page 1400 (4 of PDF): “Node 6, discovering the message is for itself,
replaces the destination address by the source address

==Group 4==

* What were the purposes envisioned for computer networks? How do those compare with the uses they are put to today?

Networks were envisioned as providing remote access to other computers, because useful resources such as computing power, large databases, and non-portable software were local to a particular computer, not themselves shared over the network.

Today, we use networks mostly for sharing data, although with services like Amazon AWS, we're starting to share computing resources again. We're also moving to support collaboration (e.g. Google Docs, GitHub, etc.).

* What sort of resources were shared? What resources are shared today?

Computing power was the key resource being shared; today, it's access to data. (See above.)

* What network architecture did they envision? Do we still have the same architecture?

Surprisingly, yes: modern networks have substantially similar architecures to the ones described in these papers.
Packet-switched networks are now ubiquitous. We no longer bother with circuit-switching even for telephony, in contrast to the assumption that non-network data would continue to use the circuit-switched common-carrier network.

* What surprised you about this paper?

We were surprised by the accuracy of the predictions given how early the paper was written — even things like electronic banking. Also surprising were technological advances since the paper was written, such as data transfer speeds (we have networks that are faster than the integrated bus in the Alto), and the predicted resolution requirements (which we are nowhere near meeting). The amount of detail in the description of the 'mouse pointing device' was interesting too.

* What was unclear?

Nothing significant; we're looking at these with the benefit of hindsight.

==Summary of the discussion from lecture==
Anil's view is that even these days we can imagine Computer Networks as more of a resource sharing platform. For example when we access the web or search Google we are making use of the resource sharing facilitated by the Internet(Network of interconnected Computer Networks). It's not possible to put 20,000 computers in our basements’, instead the Internet facilitates access to computing power/databases which are built of hundred thousands of computers. In fact Google and other popular search engines has a local copy of the entire web in their data centers, centralized copy of a large distributed system. Kind of a contradictory phenomenon if you think about in terms of the design goals of the distributed system.

Another important takeaway from the discussion was the point that "Early to market/ first player" with a new product/solution to a niche problem and the one which offer solutions based on simple mechanisms as opposed to one relying on complex mechanism gets adopted faster. Classic example is the Internet. ARPANET which was supposed to be an academic research project which was based on simple mechanisms, open and first of its kind got adopted widely and evolved in to the Internet as we see it today. It is to note that this approach is not without its own drawbacks example being the security aspects were not factored in while designing the ARPANET since it was intended to be a network between trusted parties, which was fine then. But when ARPANET evolved in to the Internet, security aspect was one area which required a major focus on. In Silicon Valley the focus is on being the "first player" in a niche market to meet that objective often simple framework/mechanisms are used. In doing so there is also a possibility of leaving out some components which can turn out to be a vital missing link, recent example being security flaw in 'snapchat' that lead to user data being exposed.

DistOS 2014W Lecture 3

2014-03-14T21:01:38Z

Gbooth: /* Discussion */

==The Early Internet (Jan. 14)==

* [https://homeostasis.scs.carleton.ca/~soma/distos/2014w/kahn1972-resource.pdf Robert E. Kahn, "Resource-Sharing Computer Communications Networks" (1972)] [http://dx.doi.org/10.1109/PROC.1972.8911 (DOI)]
* [https://archive.org/details/ComputerNetworks_TheHeraldsOfResourceSharing Computer Networks: The Heralds of Resource Sharing (1972)] - video

== Questions to consider: ==
# What were the purposes envisioned for computer networks? How do those compare with the uses they are put to today?
# What sort of resources were shared? What resources are shared today?
# What network architecture did they envision? Do we still have the same architecture?
# What surprised you about this paper?
# What was unclear?

==Group 1==
=== Discussion ===
The video was mostly a summary of Kahn's paper. It was outlined that process mitigation could be done through different zones of air traffic control. Back then, a "distributed OS" meant something different than we normally think about it now. This is because, when the paper was written, many people would be remotely logging onto a single machine. This type of infrastructure is very much like the cloud infrastructure that we see talk about and see today.

The Alto paper referenced Kahn's paper, and the Alto designers had the foresight to see that networks such as ARPANET would be necessary. However, there are still some questions that come up in discussion, such as:
* Would it be useful to have a co-processor responsible for maintaining shared resources even today? Would this be like the IMPs of ARPANET?
Today, computers are usually so fast that it doesn't really seem to matter. This is still interesting to ruminate on, though.

=== Questions ===

'''What were the purposes envisioned for computer networks?'''

The main purposes envisioned were:
* Big computation
* Storage
* Resource sharing
Essentially, being able to "have a library on a hard disk".

'''How do those compare with the uses they are put to today?'''

Today, those things/goals are being done, but we are mostly seeing communication-based things such as instant messaging and email.

'''What sort of resources were shared?'''

The main resources being shared were databases and CPU time.

'''What resources are shared today?'''

Storage is the main resource being shared today.

'''What network architecture did they envision? '''

The network architecture would make use of pack-switching. There would be a checksum and acknowledge on each packet and the IMPs were the network interface, and the routers.

'''Do we still have the same architecture?'''

Although, packet-switching definitely won, we do not have the same architecture now as the IP doesn't have a checksum or acknowledge. But TCP does have an end-to-end checksum and acknowledge. Kahn went on to learn fro the errors of ARPANet to design TCP/IP. Also, the job of the network interface and router have now been decoupled.

'''What surprised you about this paper?'''

Everything was surprising about this paper. How were they able to dl all of this? A network interface card and router were the size of a fridge! Some general things of note:
* High-level languages
* Bootstrapping protocols, bootstrapping applications
* Primitive computers
* Desktop publishing
* The logistics of running a cable from one university to another
* How old the idea of distributed operating system is

'''What was unclear?'''
Much of the more technical specifications were unclear, but we mostly skipped over those

==Group 2==
1. The main purpose of early networks was resource sharing. Abstraction for transmission. Message reliability was a by-product. The underlying idea is the same.

2. Specialized Hardware/software and information sharing. super set of sharing.

3. AD-HOC routing, it was TCP without saying it. Largely unchanged today.

==Group 3==
===Envisioned computer network purposes===
* Improving reliability of services, due to redundant resource sets
* Resource sharing
* Usage modes:t
** Users can use a remote terminal, from a remote office or home, to access those resources.
** Would allow centralization of resources, to improve ease of management and do away with inefficiencies
* Allow specialization of various sites. rather than each site trying to do it all
* Distributed simulations (notably air traffic control)

Information-sharing is still relevant today, especially in research and large simulations. Remote access has mostly devolved into a specialized need.

===Resources shared===
* Computing resources (especially expensive mainframes)
* Data sets

===Network architecture===
* A primitive layered architecture
* Dedicated routing functions
* Various topologies:
** star
** loop
** bus
* Primarily (packet|mesage)-switched
** Circuit-switching too expensive and has large setup times
** Doesn't require committing resources
* Primitive flow control and buffering
* Predates proper congestion control such as Van Jacobsen's slow start
* Ad-hoc routing or based on something similar to RIP
* Anticipation of elephants and mice latency issues
* Unlike modern internet, error control and retransmission at every step

The architecture today is similar, but the link-layer is very different: use of Ethernet and ATM. The modern internet is a collection of autonomous systems, not a single network. Routing propogation is now large-scale, and semi-automated (e.g., BGP externally, IS-IS and OSPF internally)

===Surprising aspects===

===Unclear portions===
* Weird packet format: Page 1400 (4 of PDF): “Node 6, discovering the message is for itself,
replaces the destination address by the source address

==Group 4==

* What were the purposes envisioned for computer networks? How do those compare with the uses they are put to today?

Networks were envisioned as providing remote access to other computers, because useful resources such as computing power, large databases, and non-portable software were local to a particular computer, not themselves shared over the network.

Today, we use networks mostly for sharing data, although with services like Amazon AWS, we're starting to share computing resources again. We're also moving to support collaboration (e.g. Google Docs, GitHub, etc.).

* What sort of resources were shared? What resources are shared today?

Computing power was the key resource being shared; today, it's access to data. (See above.)

* What network architecture did they envision? Do we still have the same architecture?

Surprisingly, yes: modern networks have substantially similar architecures to the ones described in these papers.
Packet-switched networks are now ubiquitous. We no longer bother with circuit-switching even for telephony, in contrast to the assumption that non-network data would continue to use the circuit-switched common-carrier network.

* What surprised you about this paper?

We were surprised by the accuracy of the predictions given how early the paper was written — even things like electronic banking. Also surprising were technological advances since the paper was written, such as data transfer speeds (we have networks that are faster than the integrated bus in the Alto), and the predicted resolution requirements (which we are nowhere near meeting). The amount of detail in the description of the 'mouse pointing device' was interesting too.

* What was unclear?

Nothing significant; we're looking at these with the benefit of hindsight.

==Summary of the discussion from lecture==
Anil's view is that even these days we can imagine Computer Networks as more of a resource sharing platform. For example when we access the web or search Google we are making use of the resource sharing facilitated by the Internet(Network of interconnected Computer Networks). It's not possible to put 20,000 computers in our basements’, instead the Internet facilitates access to computing power/databases which are built of hundred thousands of computers. In fact Google and other popular search engines has a local copy of the entire web in their data centers, centralized copy of a large distributed system. Kind of a contradictory phenomenon if you think about in terms of the design goals of the distributed system.

Another important takeaway from the discussion was the point that "Early to market/ first player" with a new product/solution to a niche problem and the one which offer solutions based on simple mechanisms as opposed to one relying on complex mechanism gets adopted faster. Classic example is the Internet. ARPANET which was supposed to be an academic research project which was based on simple mechanisms, open and first of its kind got adopted widely and evolved in to the Internet as we see it today. It is to note that this approach is not without its own drawbacks example being the security aspects were not factored in while designing the ARPANET since it was intended to be a network between trusted parties, which was fine then. But when ARPANET evolved in to the Internet, security aspect was one area which required a major focus on. In Silicon Valley the focus is on being the "first player" in a niche market to meet that objective often simple framework/mechanisms are used. In doing so there is also a possibility of leaving out some components which can turn out to be a vital missing link, recent example being security flaw in 'snapchat' that lead to user data being exposed.

DistOS 2014W Lecture 3

2014-03-14T21:00:35Z

Gbooth: /* Group 1 */

==The Early Internet (Jan. 14)==

* [https://homeostasis.scs.carleton.ca/~soma/distos/2014w/kahn1972-resource.pdf Robert E. Kahn, "Resource-Sharing Computer Communications Networks" (1972)] [http://dx.doi.org/10.1109/PROC.1972.8911 (DOI)]
* [https://archive.org/details/ComputerNetworks_TheHeraldsOfResourceSharing Computer Networks: The Heralds of Resource Sharing (1972)] - video

== Questions to consider: ==
# What were the purposes envisioned for computer networks? How do those compare with the uses they are put to today?
# What sort of resources were shared? What resources are shared today?
# What network architecture did they envision? Do we still have the same architecture?
# What surprised you about this paper?
# What was unclear?

==Group 1==
=== Discussion ===
The video was mostly a summary of Kahn's paper. It was outlined that process mitigation could be done through different zones of air traffic control. Back then, a "distributed OS" meant something different than we normally think about it now. This is because, when the paper was written, many people would be remotely logging onto a single machine. This type of infrastructure is very much like the cloud infrastructure that we see talk about and see today.

The Alto paper referenced Kahn's paper, and the Alto designers had the foresight to see that networks such as ARPANet would be necessary. However, there are still some questions that come up in discussion, such as:
* Would it be useful to have a co-processor responsible for maintaining shared resources even today? Would this be like the IMPs of ARPANet?
Today, computers are usually so fast that it doesn't really seem to matter. This is still interesting to ruminate on, though.

=== Questions ===

'''What were the purposes envisioned for computer networks?'''

The main purposes envisioned were:
* Big computation
* Storage
* Resource sharing
Essentially, being able to "have a library on a hard disk".

'''How do those compare with the uses they are put to today?'''

Today, those things/goals are being done, but we are mostly seeing communication-based things such as instant messaging and email.

'''What sort of resources were shared?'''

The main resources being shared were databases and CPU time.

'''What resources are shared today?'''

Storage is the main resource being shared today.

'''What network architecture did they envision? '''

The network architecture would make use of pack-switching. There would be a checksum and acknowledge on each packet and the IMPs were the network interface, and the routers.

'''Do we still have the same architecture?'''

Although, packet-switching definitely won, we do not have the same architecture now as the IP doesn't have a checksum or acknowledge. But TCP does have an end-to-end checksum and acknowledge. Kahn went on to learn fro the errors of ARPANet to design TCP/IP. Also, the job of the network interface and router have now been decoupled.

'''What surprised you about this paper?'''

Everything was surprising about this paper. How were they able to dl all of this? A network interface card and router were the size of a fridge! Some general things of note:
* High-level languages
* Bootstrapping protocols, bootstrapping applications
* Primitive computers
* Desktop publishing
* The logistics of running a cable from one university to another
* How old the idea of distributed operating system is

'''What was unclear?'''
Much of the more technical specifications were unclear, but we mostly skipped over those

==Group 2==
1. The main purpose of early networks was resource sharing. Abstraction for transmission. Message reliability was a by-product. The underlying idea is the same.

2. Specialized Hardware/software and information sharing. super set of sharing.

3. AD-HOC routing, it was TCP without saying it. Largely unchanged today.

==Group 3==
===Envisioned computer network purposes===
* Improving reliability of services, due to redundant resource sets
* Resource sharing
* Usage modes:t
** Users can use a remote terminal, from a remote office or home, to access those resources.
** Would allow centralization of resources, to improve ease of management and do away with inefficiencies
* Allow specialization of various sites. rather than each site trying to do it all
* Distributed simulations (notably air traffic control)

Information-sharing is still relevant today, especially in research and large simulations. Remote access has mostly devolved into a specialized need.

===Resources shared===
* Computing resources (especially expensive mainframes)
* Data sets

===Network architecture===
* A primitive layered architecture
* Dedicated routing functions
* Various topologies:
** star
** loop
** bus
* Primarily (packet|mesage)-switched
** Circuit-switching too expensive and has large setup times
** Doesn't require committing resources
* Primitive flow control and buffering
* Predates proper congestion control such as Van Jacobsen's slow start
* Ad-hoc routing or based on something similar to RIP
* Anticipation of elephants and mice latency issues
* Unlike modern internet, error control and retransmission at every step

The architecture today is similar, but the link-layer is very different: use of Ethernet and ATM. The modern internet is a collection of autonomous systems, not a single network. Routing propogation is now large-scale, and semi-automated (e.g., BGP externally, IS-IS and OSPF internally)

===Surprising aspects===

===Unclear portions===
* Weird packet format: Page 1400 (4 of PDF): “Node 6, discovering the message is for itself,
replaces the destination address by the source address

==Group 4==

* What were the purposes envisioned for computer networks? How do those compare with the uses they are put to today?

Networks were envisioned as providing remote access to other computers, because useful resources such as computing power, large databases, and non-portable software were local to a particular computer, not themselves shared over the network.

Today, we use networks mostly for sharing data, although with services like Amazon AWS, we're starting to share computing resources again. We're also moving to support collaboration (e.g. Google Docs, GitHub, etc.).

* What sort of resources were shared? What resources are shared today?

Computing power was the key resource being shared; today, it's access to data. (See above.)

* What network architecture did they envision? Do we still have the same architecture?

Surprisingly, yes: modern networks have substantially similar architecures to the ones described in these papers.
Packet-switched networks are now ubiquitous. We no longer bother with circuit-switching even for telephony, in contrast to the assumption that non-network data would continue to use the circuit-switched common-carrier network.

* What surprised you about this paper?

We were surprised by the accuracy of the predictions given how early the paper was written — even things like electronic banking. Also surprising were technological advances since the paper was written, such as data transfer speeds (we have networks that are faster than the integrated bus in the Alto), and the predicted resolution requirements (which we are nowhere near meeting). The amount of detail in the description of the 'mouse pointing device' was interesting too.

* What was unclear?

Nothing significant; we're looking at these with the benefit of hindsight.

==Summary of the discussion from lecture==
Anil's view is that even these days we can imagine Computer Networks as more of a resource sharing platform. For example when we access the web or search Google we are making use of the resource sharing facilitated by the Internet(Network of interconnected Computer Networks). It's not possible to put 20,000 computers in our basements’, instead the Internet facilitates access to computing power/databases which are built of hundred thousands of computers. In fact Google and other popular search engines has a local copy of the entire web in their data centers, centralized copy of a large distributed system. Kind of a contradictory phenomenon if you think about in terms of the design goals of the distributed system.

Another important takeaway from the discussion was the point that "Early to market/ first player" with a new product/solution to a niche problem and the one which offer solutions based on simple mechanisms as opposed to one relying on complex mechanism gets adopted faster. Classic example is the Internet. ARPANET which was supposed to be an academic research project which was based on simple mechanisms, open and first of its kind got adopted widely and evolved in to the Internet as we see it today. It is to note that this approach is not without its own drawbacks example being the security aspects were not factored in while designing the ARPANET since it was intended to be a network between trusted parties, which was fine then. But when ARPANET evolved in to the Internet, security aspect was one area which required a major focus on. In Silicon Valley the focus is on being the "first player" in a niche market to meet that objective often simple framework/mechanisms are used. In doing so there is also a possibility of leaving out some components which can turn out to be a vital missing link, recent example being security flaw in 'snapchat' that lead to user data being exposed.

DistOS 2014W Lecture 3

2014-03-14T20:46:04Z

Gbooth: /* Questions to consider: */

==The Early Internet (Jan. 14)==

* [https://homeostasis.scs.carleton.ca/~soma/distos/2014w/kahn1972-resource.pdf Robert E. Kahn, "Resource-Sharing Computer Communications Networks" (1972)] [http://dx.doi.org/10.1109/PROC.1972.8911 (DOI)]
* [https://archive.org/details/ComputerNetworks_TheHeraldsOfResourceSharing Computer Networks: The Heralds of Resource Sharing (1972)] - video

== Questions to consider: ==
# What were the purposes envisioned for computer networks? How do those compare with the uses they are put to today?
# What sort of resources were shared? What resources are shared today?
# What network architecture did they envision? Do we still have the same architecture?
# What surprised you about this paper?
# What was unclear?

==Group 1==
* video was mostly a summary of Kahn's paper
* process migration through different zones of air traffic control
* "distributed OS" meant something different than we normally think about, because many people would log in remotely to a single machine, it is very much like cloud infrastructure that we talk about today
* alto paper makes reference to Kahn's paper, and the alto designers had the foresight to see that networks like arpanet would be necessary
* would it be useful to have a co-processor responsible for maintaining shared resources even today? Like the IMPs of the arpanet? Today, computers are usually so fast it doesn't really matter.

=== Questions ===

* What were the purposes envisioned for computer networks?
** big computation, storage, resource sharing - "having a library on a hard disk"

* How do those compare with the uses they are put to today?
** those things are being done, but mostly communication like instant messaging, email

* What sort of resources were shared?
** databases, CPU time

* What resources are shared today?
** mostly storage

* What network architecture did they envision?
** they had a checksum and acknowledge on each packet
** the IMPs were the network interface and the routers
** packet-switching

* Do we still have the same architecture?
** packet-switching definitely won
** no, now IP doesn't checksum or acknowledge, but TCP has end-to-end checksum and acknowledge
** Kahn went on to learn from the errors of arpanet to design TCP/IP
** the job of network interface and router have been decoupled

* What surprised you about this paper?
** everything
** how they were able to do this
** a network interface card and router was the size of a fridge
** high-level languages
** bootstrap protocol, bootstrapping an application
** primitive computers
** desktop publishing
** the logistics of running a cable from one university to another
** how old the idea of distributed operating systems is

* What was unclear?
** much of the more technical specifications, but we mostly skipped over those

==Group 2==
1. The main purpose of early networks was resource sharing. Abstraction for transmission. Message reliability was a by-product. The underlying idea is the same.

2. Specialized Hardware/software and information sharing. super set of sharing.

3. AD-HOC routing, it was TCP without saying it. Largely unchanged today.

==Group 3==
===Envisioned computer network purposes===
* Improving reliability of services, due to redundant resource sets
* Resource sharing
* Usage modes:t
** Users can use a remote terminal, from a remote office or home, to access those resources.
** Would allow centralization of resources, to improve ease of management and do away with inefficiencies
* Allow specialization of various sites. rather than each site trying to do it all
* Distributed simulations (notably air traffic control)

Information-sharing is still relevant today, especially in research and large simulations. Remote access has mostly devolved into a specialized need.

===Resources shared===
* Computing resources (especially expensive mainframes)
* Data sets

===Network architecture===
* A primitive layered architecture
* Dedicated routing functions
* Various topologies:
** star
** loop
** bus
* Primarily (packet|mesage)-switched
** Circuit-switching too expensive and has large setup times
** Doesn't require committing resources
* Primitive flow control and buffering
* Predates proper congestion control such as Van Jacobsen's slow start
* Ad-hoc routing or based on something similar to RIP
* Anticipation of elephants and mice latency issues
* Unlike modern internet, error control and retransmission at every step

The architecture today is similar, but the link-layer is very different: use of Ethernet and ATM. The modern internet is a collection of autonomous systems, not a single network. Routing propogation is now large-scale, and semi-automated (e.g., BGP externally, IS-IS and OSPF internally)

===Surprising aspects===

===Unclear portions===
* Weird packet format: Page 1400 (4 of PDF): “Node 6, discovering the message is for itself,
replaces the destination address by the source address

==Group 4==

* What were the purposes envisioned for computer networks? How do those compare with the uses they are put to today?

Networks were envisioned as providing remote access to other computers, because useful resources such as computing power, large databases, and non-portable software were local to a particular computer, not themselves shared over the network.

Today, we use networks mostly for sharing data, although with services like Amazon AWS, we're starting to share computing resources again. We're also moving to support collaboration (e.g. Google Docs, GitHub, etc.).

* What sort of resources were shared? What resources are shared today?

Computing power was the key resource being shared; today, it's access to data. (See above.)

* What network architecture did they envision? Do we still have the same architecture?

Surprisingly, yes: modern networks have substantially similar architecures to the ones described in these papers.
Packet-switched networks are now ubiquitous. We no longer bother with circuit-switching even for telephony, in contrast to the assumption that non-network data would continue to use the circuit-switched common-carrier network.

* What surprised you about this paper?

We were surprised by the accuracy of the predictions given how early the paper was written — even things like electronic banking. Also surprising were technological advances since the paper was written, such as data transfer speeds (we have networks that are faster than the integrated bus in the Alto), and the predicted resolution requirements (which we are nowhere near meeting). The amount of detail in the description of the 'mouse pointing device' was interesting too.

* What was unclear?

Nothing significant; we're looking at these with the benefit of hindsight.

==Summary of the discussion from lecture==
Anil's view is that even these days we can imagine Computer Networks as more of a resource sharing platform. For example when we access the web or search Google we are making use of the resource sharing facilitated by the Internet(Network of interconnected Computer Networks). It's not possible to put 20,000 computers in our basements’, instead the Internet facilitates access to computing power/databases which are built of hundred thousands of computers. In fact Google and other popular search engines has a local copy of the entire web in their data centers, centralized copy of a large distributed system. Kind of a contradictory phenomenon if you think about in terms of the design goals of the distributed system.

Another important takeaway from the discussion was the point that "Early to market/ first player" with a new product/solution to a niche problem and the one which offer solutions based on simple mechanisms as opposed to one relying on complex mechanism gets adopted faster. Classic example is the Internet. ARPANET which was supposed to be an academic research project which was based on simple mechanisms, open and first of its kind got adopted widely and evolved in to the Internet as we see it today. It is to note that this approach is not without its own drawbacks example being the security aspects were not factored in while designing the ARPANET since it was intended to be a network between trusted parties, which was fine then. But when ARPANET evolved in to the Internet, security aspect was one area which required a major focus on. In Silicon Valley the focus is on being the "first player" in a niche market to meet that objective often simple framework/mechanisms are used. In doing so there is also a possibility of leaving out some components which can turn out to be a vital missing link, recent example being security flaw in 'snapchat' that lead to user data being exposed.

DistOS 2014W Lecture 17

2014-03-13T14:47:43Z

Gbooth: /* Point of lit review */

== What is a Literature Review? ==
We shouldn't summarize everything. Instead, we should be doing a critical analysis/comparison of the all the work in a chosen area. We should cover all of the significant points in said chosen area.

Tips for a literature review with Anil:
* Try an organize the papers thematically rather than presenting them all linearly (i.e., "This person did this, this person did this, etc.")
* Categorize papers into several themes/categories that relate to your topic and present the papers as part of a theme. This makes it easier to compare/contrast similar papers and to see how all the different chunks of knowledge/work relates.

== Point of lit review ==

With a research proposal, you would be asking, "What can be done to plug the holes here?" The point of a literature review, in this sense, is to try and offer new interpretations, theoretical approaches, or other ideas.

A more traditional literature review comprises of providing a critical overview of the current state of research efforts.

A stand alone literature review of articles best fits what we're doing in this class. This typically involves:
* Overview and analysis of the current state of the art in your chosen topic.
* Evaluate and compare all the research in this chosen area.
* It might be difficult to really show weaknesses and gaps in the area as you tend to need to be an expert in the area to find these gaps. But, you can criticize the overall body of work and say what's missing and give general areas of future work.

== Structure of a Research Paper ==
* Abstract
* Introduction
* Literature Review (about 1/4 to 1/3 of your thesis, typically, so if you can do the literature review for your thesis in a class, that's a great bonus)
* Methods
* Results
* Discussion
* Conclusion

== Finding Sources ==

A good way to go is to first look at tertiary sources (e.g., Wikipedia articles) to get a general idea of the area and what it's about. Following this, you can go into secondary sources to determine the history and general themes of the area. When you have a better understanding of the area overall, jump into your primary sources and get into the "nitty gritty" of the most current research.

A good way to find articles and papers to cite is "footnote chasing". In one of the papers you want to include, look at their related work and footnotes. These tend to be good citations that you should look up and include in your work--it helps you find out about the area as a whole, giving you a good base to start on.

== Tips Writing the Literature Review ==

'''Step 1:'''
Have one document that has a list of all your sources. With each source in the document, have a short paragraph/blurb of what the paper is about, how it works, what they did well/didn't do well, etc. This will show that you understood the papers and will save you having to read them all again later.

'''Step 2:'''
Once again, thematic organization. Start to classify your papers into a few categories relating to your topic. This makes it easier to do things such as discoursing on the area overall in the introduction, abstract, etc. It also allows you to better organize the paper later and to compare/contrast them.

'''Step 3:'''
Once you have the categories, this is where the paragraphs you've written in Step 1 come in handy. You can write an introduction for each of your categories then just dump in the paragraphs from your document. Following this, you can polish your sections and better integrate them.

'''General Notes:'''

* Have a good introduction, outlining exactly what you're going to cover, why it's important, etc.
* Make sure to keep things high-level--you shouldn't have to be an expert in the sub-topic you've chosen to be able to read and understand your literature review.
* Make sure to be selective with what your'e including. Include all of the really current things and what is historically relevant for your topic (i.e., either very current work or very important, groundbreaking work for the topic). Intermediary work doesn't always need to be included. Don't include citations just to get your citation count up, this actually detracts from your literature review.

== Final Notes ==

* Focus on having a good introduction.
* Setting up categories properly.
* Having a good introduction for each category.
* A good overview of each paper in the category.
* If possible, a table to summarize everything from a section.

Really avoid coming to the conclusion that this work is great, but it would be really great if this existed. And then you find out that that actually exists. Make sure before you reach a conclusion like this, that it '''doesn't''' exist already, otherwise your work doesn't look thorough.

DistOS 2014W Lecture 17

2014-03-13T14:44:28Z

Gbooth: /* Tips Writing the Literature Review */

DistOS 2014W Lecture 17

2014-03-13T14:33:35Z

Gbooth: /* What is a Literature Review? */

DistOS 2014W Lecture 17

2014-03-13T14:33:12Z

Gbooth: /* Tips Writing the Literature Review */

DistOS 2014W Lecture 17

2014-03-13T14:30:03Z

Gbooth: /* Structure of a Research Paper */

DistOS 2014W Lecture 17

2014-03-13T14:29:20Z

Gbooth: /* Tips Writing the Literature Review */

DistOS 2014W Lecture 17

2014-03-13T14:27:46Z

Gbooth: Created page with "== What is a Literature Review? == We shouldn't summarize everything. Instead, we should be doing a critical analysis/comparison of the all the work in a chosen area. We shoul..."

DistOS 2014W Lecture 16

2014-03-13T02:52:06Z

Gbooth: /* Embarrassingly Parallell */

Public Resource Computing

== Outline for upcoming lectures ==

All the papers that would be covered in upcoming lectures have been posted on Wiki. These papers will be more difficult in comparison to the papers we have covered so far, so we should be prepared to allot more time for studying these papers and come prepared in class. We may abandon the way of discussing the papers in group and instead everyone would ask the questions about what,they did not understand from paper so it would allow us to discuss the technical detail better.
Professor will not be taking the next class, instead our TA would discuss the two papers on how to conduct a literature survey, which should help with our projects.
The rest of the papers will deal with many closely related systems. In particular, we will be looking at distributed hash tables and systems that use distributed hash tables.

After looking at the material from today, we will also be looking at how we can get the kind of distribution that we get with public resource computing, but with greater flexibility.

== Project proposal==
There were 11 proposals and out of which professor found 4 to be in the state of getting accepted and has graded them 10/10. professor has mailed to everyone with the feedback about the project proposal so that we can incorporate those comments and submit the project proposals by coming Saturday ( the extended deadline). the deadline has been extended so that every one can work out the flaws in their proposal and get the best grades (10/10).
Project Presentation are to be held on 1st and 3rd april. People who got 10/10 should be ready to present on Tuesday as they are ahead and better prepared for it, there should be 6 presentation on Tuesday and rest on Thursday.
Under-grad will have their final exam on 24th April. 24th April is also the date to turn-in the final project report.

== Public Resource Computing ==

The paper assigned for readings were on SETI and BOINC. BOINC is the system SETI is built upon, there are other projects running on the same system like Folding@home etc. In particular, we want to discuss the following:
What is public resource computing? How does public resource computing relate to the various computational models and systems that we have seen this semester? How are they similar in design, purpose, and technologies? How is it different?

The main purpose of public resource computing was to have a universally accessible, easy-to-use, way of sharing resources. This is interesting as it differs from some of the systems we have looked at that deal with the sharing of information rather than resources.

For computational parallelism, you need a highly parallel problem. SETI@home and folding@home give examples of such problems. In public resource computing, particularly with the BOINC system, you divide the problem into work units. People voluntarily install the clients on their machines, running the program to work on work units that are sent to their clients in return for credits. In the past, it has been institutes, such as universities, running services with other people connecting in to use said service. Public resource computing turns this use case on its head, having the institute (e.g., the university) being the one using the service while other people are contributing to said service voluntarily. In the files systems we have covered so far, people would want access to the files stored in a network system, here a system wants to access people's machines to utilize the processing power of their machine. Since they are contributing voluntarily, how do you make these users care about the system if something were to happen? The gamification of the system causes many users to become invested in the system. People are doing work for credits and those with the most credits are showcased as major contributors. They can also see the amount of resources (e.g., process cycles) they have devoted to the cause on the GUI of the installed client. When the client produces results for the work unit it was processing, it sends the result to the server.

For fault tolerance, such as malicious clients are faulty processors, redundant computing is done. Work units are processed multiple times.
Work units are later taken off of the clients as dictated by the following two cases:
# They receive the number of results, '''n''', for a certain work unit, they take the answer that the majority gave.
# They have transmitted a work unit '''m''' times and have not gotten back the n expected responses.
It should be noted that, in doing this, it is possible that some work units are never processed. The probability of this happening can be reduced by increasing the value of '''m''', though.

=== General Discussion ===
So, given all this, how would we generally define public resource computing/public interest computing? It is essentially using the public as a resource--you are voluntarily giving up your extra compute cycles for projects (this is a little like donating blood--public resource computing is a vampire). Looking at public resource computing like this, we can contrast it with a botnet. What is the difference? Both system are utilizing client machines to perform/aid in some task. The answer: consent. You are consensually contributing to a project rather than being (unknowingly) forced to. Other differences are the ends/resources that you want as well as reliability. With a botnet, you can trust that a higher proportion of your users are following your commands exactly (as they have no idea they are performing them). Whereas, in public resource computing, how can you guarantee that clients are doing what you want?

=== Comparisons ===
Basic Comparison with other File systems , we have covered so far -

# Use-Cases have been turned on their head. In the files systems we have covered so far, People would want access to the files stored in a network system, here a system wants to access people's machines to utilize the processing power of their machine.
# In other file systems it was about many clients sharing the data, here it is more about sharing the processing power. In Folding@home, the system can store some of its data at client's storage but that is not the public resource computing's main focus.
# It is nothing like systems like OceanStore where there is no centralized authority, in BOINC the master/slave relation between the centralized server and the clients installed across users' machine can still be visualized and it is more like GFS in that sense because GFS also had a centralized metadata server.
# Public resource systems are like BOTNETs but people install these clients with consent and there is no need for communication between the clients ( it is not peer to peer network). It could be made to communicate at peer to peer level but it would risk security as clients are not trusted in the network
# Skype was modelled much like a public resource computing network (before Microsoft took over). The whole model of Skype was that the infrastructure just ran on the computers of those who had downloaded the clients (like a consensual botnet). Once a person downloaded the client, they would be a part of this system. As with public resource computing, you would donate some of your resources in order to support the distributed infrastructure. It was also not assumed that everyone was reliable, but would assume that some people are reliable some of the time. The network would choose super nodes to act as routers. These super nodes would be the machines with higher reliability and better processing powers. After MS' takeover the supernodes have been centralized and the election of supernodes functionality has been removed from the system.

=== Trust Model and Fault Tolerance ===

In this central model, you have a central resource and distribute work to clients who proess the work and send back results. Once they do, you can send them more work. In this model, can you trust the client to complete the computation successfully? The answer is not necessarily--there could be untrustworthy clients sending back rubbish answers.

So, how does SETI address the questions of fault tolerance ? They use replication for reliability and redundant computing. Work units are assigned to multiple clients and the results that are returned to server can be analyzed to find the outliers in order to detect the malicious users but that addresses the situations of fault tolerance from client perspective.

However, SETI has a centralized server, which can go down and when it does, it uses exponential back off to push back the clients and ask them to wait before sending the result again. But, whenever a server comes back up many clients may try to access the server at once and may crash the server once again--essentially, the server will have manufactured its own DDOS attack due to the server's own inadequacies.The Exponential back-off approach is similar to the one adopted in resolving the TCP congestion. It can be noted that there is almost no reliability engineering here, though. These are just standard servers running with one backup that is manually failed over to. This can give an idea of how asymmetric the relationship is.

One reason that this might be is to look at the actual service and who is running it. Reliability for a service is high when a high amount of people use the service and, hence, would be upset were the service to go down. In this case, it's the university using the service and clients are helping out by providing resources. If the service goes down, it is the university's fault and they can individually deal with it. It is interesting to compare this strategy to highly reliable systems like Ceph or Oceanstore, which could recover the data in case a node crashes.

The idea of redundancy relates to Oceanstore a little, but how would Oceanstore map onto this idea of public resource computing? In place of the Oceanstore metadata cluster, there is a central server. In place of the data store, there are machines doing computation. Specifically, mapping on this model of public resource computing is the notion of having one central thing and a bunch of outlying nodes. This is very much a master/slave relationship, though it is a voluntary one. In this relationship, CPU cycles are cheap, but bandwidth is expensive, hence showing why work units are sent infrequently. The storage is in-between--sometimes data is pushed to the clients. When this is done, the resemblance of public resource computing to Oceanstore is stronger.

=== Embarrassingly Parallell ===

When you are doing parallel computations, you have to do a imxture of computation and communication. You're doing computation separately, but you always have to do some communication. But, how much communication do you have to do for every unit of computation? In some cases there are many dependencies meaning that a high amount of communication is required (e.g., weather system simulations).

Embarrassingly parallel means that a given problem requires a minimum of communication between the pieces of work. This typically means that you have a bunch of data that you want to analyze, and it's all independent. Due to this, you can just split up and distribute the work for analysis. In an embarrassingly parallel problem, computations are trivial, due to the minimum of communication, as the more processors you add, the faster the system will run. However, problems that are not embarrassingly parallel, the system can actually slow down when more processors are added as more communication is required. With distributed systems, you either need to accept communications costs or modify abstractions to allow you to get closer to an embarrassingly parallel system. Since speedup is trivial when the problem is embarrassingly parallel, you don't get much praise for doing it.

SETI is an example of an "embarrassingly parallel" workload. The inherent nature of the problem lends itself to be divided into work-units and be computed in-parallel without any need to consolidate the results. It is called "embarrassingly parallel" because there is little to no effort required to distribute the work load in parallel.

One more example of "embarrassingly parallel" in what we have covered so far could be web-indexing in GFS. Any file system that we have discussed so far, which doesn't trust the clients can be modelled to work as public sharing system.

Note: Public resource computing is also very similar to mapreduce, which we will be discussing later in the course. Make sure to keep public resource computing in mind when we reach this.

DistOS 2014W Lecture 16

2014-03-13T02:44:40Z

Gbooth: /* Comparisons */

Public Resource Computing

== Outline for upcoming lectures ==

All the papers that would be covered in upcoming lectures have been posted on Wiki. These papers will be more difficult in comparison to the papers we have covered so far, so we should be prepared to allot more time for studying these papers and come prepared in class. We may abandon the way of discussing the papers in group and instead everyone would ask the questions about what,they did not understand from paper so it would allow us to discuss the technical detail better.
Professor will not be taking the next class, instead our TA would discuss the two papers on how to conduct a literature survey, which should help with our projects.
The rest of the papers will deal with many closely related systems. In particular, we will be looking at distributed hash tables and systems that use distributed hash tables.

After looking at the material from today, we will also be looking at how we can get the kind of distribution that we get with public resource computing, but with greater flexibility.

== Project proposal==
There were 11 proposals and out of which professor found 4 to be in the state of getting accepted and has graded them 10/10. professor has mailed to everyone with the feedback about the project proposal so that we can incorporate those comments and submit the project proposals by coming Saturday ( the extended deadline). the deadline has been extended so that every one can work out the flaws in their proposal and get the best grades (10/10).
Project Presentation are to be held on 1st and 3rd april. People who got 10/10 should be ready to present on Tuesday as they are ahead and better prepared for it, there should be 6 presentation on Tuesday and rest on Thursday.
Under-grad will have their final exam on 24th April. 24th April is also the date to turn-in the final project report.

== Public Resource Computing ==

The paper assigned for readings were on SETI and BOINC. BOINC is the system SETI is built upon, there are other projects running on the same system like Folding@home etc. In particular, we want to discuss the following:
What is public resource computing? How does public resource computing relate to the various computational models and systems that we have seen this semester? How are they similar in design, purpose, and technologies? How is it different?

The main purpose of public resource computing was to have a universally accessible, easy-to-use, way of sharing resources. This is interesting as it differs from some of the systems we have looked at that deal with the sharing of information rather than resources.

For computational parallelism, you need a highly parallel problem. SETI@home and folding@home give examples of such problems. In public resource computing, particularly with the BOINC system, you divide the problem into work units. People voluntarily install the clients on their machines, running the program to work on work units that are sent to their clients in return for credits. In the past, it has been institutes, such as universities, running services with other people connecting in to use said service. Public resource computing turns this use case on its head, having the institute (e.g., the university) being the one using the service while other people are contributing to said service voluntarily. In the files systems we have covered so far, people would want access to the files stored in a network system, here a system wants to access people's machines to utilize the processing power of their machine. Since they are contributing voluntarily, how do you make these users care about the system if something were to happen? The gamification of the system causes many users to become invested in the system. People are doing work for credits and those with the most credits are showcased as major contributors. They can also see the amount of resources (e.g., process cycles) they have devoted to the cause on the GUI of the installed client. When the client produces results for the work unit it was processing, it sends the result to the server.

For fault tolerance, such as malicious clients are faulty processors, redundant computing is done. Work units are processed multiple times.
Work units are later taken off of the clients as dictated by the following two cases:
# They receive the number of results, '''n''', for a certain work unit, they take the answer that the majority gave.
# They have transmitted a work unit '''m''' times and have not gotten back the n expected responses.
It should be noted that, in doing this, it is possible that some work units are never processed. The probability of this happening can be reduced by increasing the value of '''m''', though.

=== General Discussion ===
So, given all this, how would we generally define public resource computing/public interest computing? It is essentially using the public as a resource--you are voluntarily giving up your extra compute cycles for projects (this is a little like donating blood--public resource computing is a vampire). Looking at public resource computing like this, we can contrast it with a botnet. What is the difference? Both system are utilizing client machines to perform/aid in some task. The answer: consent. You are consensually contributing to a project rather than being (unknowingly) forced to. Other differences are the ends/resources that you want as well as reliability. With a botnet, you can trust that a higher proportion of your users are following your commands exactly (as they have no idea they are performing them). Whereas, in public resource computing, how can you guarantee that clients are doing what you want?

=== Comparisons ===
Basic Comparison with other File systems , we have covered so far -

# Use-Cases have been turned on their head. In the files systems we have covered so far, People would want access to the files stored in a network system, here a system wants to access people's machines to utilize the processing power of their machine.
# In other file systems it was about many clients sharing the data, here it is more about sharing the processing power. In Folding@home, the system can store some of its data at client's storage but that is not the public resource computing's main focus.
# It is nothing like systems like OceanStore where there is no centralized authority, in BOINC the master/slave relation between the centralized server and the clients installed across users' machine can still be visualized and it is more like GFS in that sense because GFS also had a centralized metadata server.
# Public resource systems are like BOTNETs but people install these clients with consent and there is no need for communication between the clients ( it is not peer to peer network). It could be made to communicate at peer to peer level but it would risk security as clients are not trusted in the network
# Skype was modelled much like a public resource computing network (before Microsoft took over). The whole model of Skype was that the infrastructure just ran on the computers of those who had downloaded the clients (like a consensual botnet). Once a person downloaded the client, they would be a part of this system. As with public resource computing, you would donate some of your resources in order to support the distributed infrastructure. It was also not assumed that everyone was reliable, but would assume that some people are reliable some of the time. The network would choose super nodes to act as routers. These super nodes would be the machines with higher reliability and better processing powers. After MS' takeover the supernodes have been centralized and the election of supernodes functionality has been removed from the system.

=== Trust Model and Fault Tolerance ===

In this central model, you have a central resource and distribute work to clients who proess the work and send back results. Once they do, you can send them more work. In this model, can you trust the client to complete the computation successfully? The answer is not necessarily--there could be untrustworthy clients sending back rubbish answers.

So, how does SETI address the questions of fault tolerance ? They use replication for reliability and redundant computing. Work units are assigned to multiple clients and the results that are returned to server can be analyzed to find the outliers in order to detect the malicious users but that addresses the situations of fault tolerance from client perspective.

However, SETI has a centralized server, which can go down and when it does, it uses exponential back off to push back the clients and ask them to wait before sending the result again. But, whenever a server comes back up many clients may try to access the server at once and may crash the server once again--essentially, the server will have manufactured its own DDOS attack due to the server's own inadequacies.The Exponential back-off approach is similar to the one adopted in resolving the TCP congestion. It can be noted that there is almost no reliability engineering here, though. These are just standard servers running with one backup that is manually failed over to. This can give an idea of how asymmetric the relationship is.

One reason that this might be is to look at the actual service and who is running it. Reliability for a service is high when a high amount of people use the service and, hence, would be upset were the service to go down. In this case, it's the university using the service and clients are helping out by providing resources. If the service goes down, it is the university's fault and they can individually deal with it. It is interesting to compare this strategy to highly reliable systems like Ceph or Oceanstore, which could recover the data in case a node crashes.

The idea of redundancy relates to Oceanstore a little, but how would Oceanstore map onto this idea of public resource computing? In place of the Oceanstore metadata cluster, there is a central server. In place of the data store, there are machines doing computation. Specifically, mapping on this model of public resource computing is the notion of having one central thing and a bunch of outlying nodes. This is very much a master/slave relationship, though it is a voluntary one. In this relationship, CPU cycles are cheap, but bandwidth is expensive, hence showing why work units are sent infrequently. The storage is in-between--sometimes data is pushed to the clients. When this is done, the resemblance of public resource computing to Oceanstore is stronger.

=== Embarrassingly Parallell ===

SETI is an example of "embarrassingly parallel" workload where the problem has inherent nature to lend itself to be divided into work-units and be computed in-parallel without any need to consolidate the results, it is called "embarrassingly parallel" because there is little to no efforts required to distribute the work load in parallel and you don't get much praise for doing it. one more example of "embarrassingly parallel" from the file systems that we have covered so far could be web-indexing in GFS. Any file system that we have discussed so far, which doesnt trust the clients can be modeled to work as public sharing system.

Note: Public resource computing is also very similar to mapreduce, which we will be discussing later in the course. Make sure to keep public resource computing in mind when we reach this.

DistOS 2014W Lecture 16

2014-03-13T02:42:44Z

Gbooth: /* Trust Model and Fault Tolerance */

Public Resource Computing

== Outline for upcoming lectures ==

All the papers that would be covered in upcoming lectures have been posted on Wiki. These papers will be more difficult in comparison to the papers we have covered so far, so we should be prepared to allot more time for studying these papers and come prepared in class. We may abandon the way of discussing the papers in group and instead everyone would ask the questions about what,they did not understand from paper so it would allow us to discuss the technical detail better.
Professor will not be taking the next class, instead our TA would discuss the two papers on how to conduct a literature survey, which should help with our projects.
The rest of the papers will deal with many closely related systems. In particular, we will be looking at distributed hash tables and systems that use distributed hash tables.

After looking at the material from today, we will also be looking at how we can get the kind of distribution that we get with public resource computing, but with greater flexibility.

== Project proposal==
There were 11 proposals and out of which professor found 4 to be in the state of getting accepted and has graded them 10/10. professor has mailed to everyone with the feedback about the project proposal so that we can incorporate those comments and submit the project proposals by coming Saturday ( the extended deadline). the deadline has been extended so that every one can work out the flaws in their proposal and get the best grades (10/10).
Project Presentation are to be held on 1st and 3rd april. People who got 10/10 should be ready to present on Tuesday as they are ahead and better prepared for it, there should be 6 presentation on Tuesday and rest on Thursday.
Under-grad will have their final exam on 24th April. 24th April is also the date to turn-in the final project report.

== Public Resource Computing ==

The paper assigned for readings were on SETI and BOINC. BOINC is the system SETI is built upon, there are other projects running on the same system like Folding@home etc. In particular, we want to discuss the following:
What is public resource computing? How does public resource computing relate to the various computational models and systems that we have seen this semester? How are they similar in design, purpose, and technologies? How is it different?

The main purpose of public resource computing was to have a universally accessible, easy-to-use, way of sharing resources. This is interesting as it differs from some of the systems we have looked at that deal with the sharing of information rather than resources.

For computational parallelism, you need a highly parallel problem. SETI@home and folding@home give examples of such problems. In public resource computing, particularly with the BOINC system, you divide the problem into work units. People voluntarily install the clients on their machines, running the program to work on work units that are sent to their clients in return for credits. In the past, it has been institutes, such as universities, running services with other people connecting in to use said service. Public resource computing turns this use case on its head, having the institute (e.g., the university) being the one using the service while other people are contributing to said service voluntarily. In the files systems we have covered so far, people would want access to the files stored in a network system, here a system wants to access people's machines to utilize the processing power of their machine. Since they are contributing voluntarily, how do you make these users care about the system if something were to happen? The gamification of the system causes many users to become invested in the system. People are doing work for credits and those with the most credits are showcased as major contributors. They can also see the amount of resources (e.g., process cycles) they have devoted to the cause on the GUI of the installed client. When the client produces results for the work unit it was processing, it sends the result to the server.

For fault tolerance, such as malicious clients are faulty processors, redundant computing is done. Work units are processed multiple times.
Work units are later taken off of the clients as dictated by the following two cases:
# They receive the number of results, '''n''', for a certain work unit, they take the answer that the majority gave.
# They have transmitted a work unit '''m''' times and have not gotten back the n expected responses.
It should be noted that, in doing this, it is possible that some work units are never processed. The probability of this happening can be reduced by increasing the value of '''m''', though.

=== General Discussion ===
So, given all this, how would we generally define public resource computing/public interest computing? It is essentially using the public as a resource--you are voluntarily giving up your extra compute cycles for projects (this is a little like donating blood--public resource computing is a vampire). Looking at public resource computing like this, we can contrast it with a botnet. What is the difference? Both system are utilizing client machines to perform/aid in some task. The answer: consent. You are consensually contributing to a project rather than being (unknowingly) forced to. Other differences are the ends/resources that you want as well as reliability. With a botnet, you can trust that a higher proportion of your users are following your commands exactly (as they have no idea they are performing them). Whereas, in public resource computing, how can you guarantee that clients are doing what you want?

=== Comparisons ===
Basic Comparison with other File systems , we have covered so far -

# Use-Cases have been turned on their head. In the files systems we have covered so far, People would want access to the files stored in a network system, here a system wants to access people's machines to utilize the processing power of their machine.
# In other file systems it was about many clients sharing the data, here it is more about sharing the processing power. In Folding@home, the system can store some of its data at client's storage but that is not the public resource computing's main focus.
# It is nothing like systems like OceanStore where there is no centralized authority, in BOINC the master/slave relation between the centralized server and the clients installed across users' machine can still be visualized and it is more like GFS in that sense because GFS also had a centralized metadata server.
# Public resource systems are like BOTNETs but people install these clients with consent and there is no need for communication between the clients ( it is not peer to peer network). It could be made to communicate at peer to peer level but it would risk security as clients are not trusted in the network

=== Trust Model and Fault Tolerance ===

In this central model, you have a central resource and distribute work to clients who proess the work and send back results. Once they do, you can send them more work. In this model, can you trust the client to complete the computation successfully? The answer is not necessarily--there could be untrustworthy clients sending back rubbish answers.

So, how does SETI address the questions of fault tolerance ? They use replication for reliability and redundant computing. Work units are assigned to multiple clients and the results that are returned to server can be analyzed to find the outliers in order to detect the malicious users but that addresses the situations of fault tolerance from client perspective.

However, SETI has a centralized server, which can go down and when it does, it uses exponential back off to push back the clients and ask them to wait before sending the result again. But, whenever a server comes back up many clients may try to access the server at once and may crash the server once again--essentially, the server will have manufactured its own DDOS attack due to the server's own inadequacies.The Exponential back-off approach is similar to the one adopted in resolving the TCP congestion. It can be noted that there is almost no reliability engineering here, though. These are just standard servers running with one backup that is manually failed over to. This can give an idea of how asymmetric the relationship is.

One reason that this might be is to look at the actual service and who is running it. Reliability for a service is high when a high amount of people use the service and, hence, would be upset were the service to go down. In this case, it's the university using the service and clients are helping out by providing resources. If the service goes down, it is the university's fault and they can individually deal with it. It is interesting to compare this strategy to highly reliable systems like Ceph or Oceanstore, which could recover the data in case a node crashes.

The idea of redundancy relates to Oceanstore a little, but how would Oceanstore map onto this idea of public resource computing? In place of the Oceanstore metadata cluster, there is a central server. In place of the data store, there are machines doing computation. Specifically, mapping on this model of public resource computing is the notion of having one central thing and a bunch of outlying nodes. This is very much a master/slave relationship, though it is a voluntary one. In this relationship, CPU cycles are cheap, but bandwidth is expensive, hence showing why work units are sent infrequently. The storage is in-between--sometimes data is pushed to the clients. When this is done, the resemblance of public resource computing to Oceanstore is stronger.

=== Embarrassingly Parallell ===

SETI is an example of "embarrassingly parallel" workload where the problem has inherent nature to lend itself to be divided into work-units and be computed in-parallel without any need to consolidate the results, it is called "embarrassingly parallel" because there is little to no efforts required to distribute the work load in parallel and you don't get much praise for doing it. one more example of "embarrassingly parallel" from the file systems that we have covered so far could be web-indexing in GFS. Any file system that we have discussed so far, which doesnt trust the clients can be modeled to work as public sharing system.

Note: Public resource computing is also very similar to mapreduce, which we will be discussing later in the course. Make sure to keep public resource computing in mind when we reach this.

DistOS 2014W Lecture 16

2014-03-13T02:40:50Z

Gbooth: /* Outline for upcoming lectures */

Public Resource Computing

== Outline for upcoming lectures ==

All the papers that would be covered in upcoming lectures have been posted on Wiki. These papers will be more difficult in comparison to the papers we have covered so far, so we should be prepared to allot more time for studying these papers and come prepared in class. We may abandon the way of discussing the papers in group and instead everyone would ask the questions about what,they did not understand from paper so it would allow us to discuss the technical detail better.
Professor will not be taking the next class, instead our TA would discuss the two papers on how to conduct a literature survey, which should help with our projects.
The rest of the papers will deal with many closely related systems. In particular, we will be looking at distributed hash tables and systems that use distributed hash tables.

After looking at the material from today, we will also be looking at how we can get the kind of distribution that we get with public resource computing, but with greater flexibility.

== Project proposal==
There were 11 proposals and out of which professor found 4 to be in the state of getting accepted and has graded them 10/10. professor has mailed to everyone with the feedback about the project proposal so that we can incorporate those comments and submit the project proposals by coming Saturday ( the extended deadline). the deadline has been extended so that every one can work out the flaws in their proposal and get the best grades (10/10).
Project Presentation are to be held on 1st and 3rd april. People who got 10/10 should be ready to present on Tuesday as they are ahead and better prepared for it, there should be 6 presentation on Tuesday and rest on Thursday.
Under-grad will have their final exam on 24th April. 24th April is also the date to turn-in the final project report.

== Public Resource Computing ==

The paper assigned for readings were on SETI and BOINC. BOINC is the system SETI is built upon, there are other projects running on the same system like Folding@home etc. In particular, we want to discuss the following:
What is public resource computing? How does public resource computing relate to the various computational models and systems that we have seen this semester? How are they similar in design, purpose, and technologies? How is it different?

The main purpose of public resource computing was to have a universally accessible, easy-to-use, way of sharing resources. This is interesting as it differs from some of the systems we have looked at that deal with the sharing of information rather than resources.

For computational parallelism, you need a highly parallel problem. SETI@home and folding@home give examples of such problems. In public resource computing, particularly with the BOINC system, you divide the problem into work units. People voluntarily install the clients on their machines, running the program to work on work units that are sent to their clients in return for credits. In the past, it has been institutes, such as universities, running services with other people connecting in to use said service. Public resource computing turns this use case on its head, having the institute (e.g., the university) being the one using the service while other people are contributing to said service voluntarily. In the files systems we have covered so far, people would want access to the files stored in a network system, here a system wants to access people's machines to utilize the processing power of their machine. Since they are contributing voluntarily, how do you make these users care about the system if something were to happen? The gamification of the system causes many users to become invested in the system. People are doing work for credits and those with the most credits are showcased as major contributors. They can also see the amount of resources (e.g., process cycles) they have devoted to the cause on the GUI of the installed client. When the client produces results for the work unit it was processing, it sends the result to the server.

For fault tolerance, such as malicious clients are faulty processors, redundant computing is done. Work units are processed multiple times.
Work units are later taken off of the clients as dictated by the following two cases:
# They receive the number of results, '''n''', for a certain work unit, they take the answer that the majority gave.
# They have transmitted a work unit '''m''' times and have not gotten back the n expected responses.
It should be noted that, in doing this, it is possible that some work units are never processed. The probability of this happening can be reduced by increasing the value of '''m''', though.

=== General Discussion ===
So, given all this, how would we generally define public resource computing/public interest computing? It is essentially using the public as a resource--you are voluntarily giving up your extra compute cycles for projects (this is a little like donating blood--public resource computing is a vampire). Looking at public resource computing like this, we can contrast it with a botnet. What is the difference? Both system are utilizing client machines to perform/aid in some task. The answer: consent. You are consensually contributing to a project rather than being (unknowingly) forced to. Other differences are the ends/resources that you want as well as reliability. With a botnet, you can trust that a higher proportion of your users are following your commands exactly (as they have no idea they are performing them). Whereas, in public resource computing, how can you guarantee that clients are doing what you want?

=== Comparisons ===
Basic Comparison with other File systems , we have covered so far -

# Use-Cases have been turned on their head. In the files systems we have covered so far, People would want access to the files stored in a network system, here a system wants to access people's machines to utilize the processing power of their machine.
# In other file systems it was about many clients sharing the data, here it is more about sharing the processing power. In Folding@home, the system can store some of its data at client's storage but that is not the public resource computing's main focus.
# It is nothing like systems like OceanStore where there is no centralized authority, in BOINC the master/slave relation between the centralized server and the clients installed across users' machine can still be visualized and it is more like GFS in that sense because GFS also had a centralized metadata server.
# Public resource systems are like BOTNETs but people install these clients with consent and there is no need for communication between the clients ( it is not peer to peer network). It could be made to communicate at peer to peer level but it would risk security as clients are not trusted in the network

=== Trust Model and Fault Tolerance ===

In this central model, you have a central resource and distribute work to clients who proess the work and send back results. Once they do, you can send them more work. In this model, can you trust the client to complete the computation successfully? The answer is not necessarily--there could be untrustworthy clients sending back rubbish answers.

So, how does SETI address the questions of fault tolerance ? They use replication for reliability and redundant computing. Work units are assigned to multiple clients and the results that are returned to server can be analyzed to find the outliers in order to detect the malicious users but that addresses the situations of fault tolerance from client perspective.

However, SETI has a centralized server, which can go down and when it does, it uses exponential back off to push back the clients and ask them to wait before sending the result again. But, whenever a server comes back up many clients may try to access the server at once and may crash the server once again--essentially, the server will have manufactured its own DDOS attack due to the server's own inadequacies.The Exponential back-off approach is similar to the one adopted in resolving the TCP congestion. It can be noted that there is almost no reliability engineering here, though. These are just standard servers running with one backup that is manually failed over to. This can give an idea of how asymmetric the relationship is.

One reason that this might be is to look at the actual service and who is running it. Reliability for a service is high when a high amount of people use the service and, hence, would be upset were the service to go down. In this case, it's the university using the service and clients are helping out by providing resources. If the service goes down, it is the university's fault and they can individually deal with it.

The idea of redundancy relates to Oceanstore a little, but how would Oceanstore map onto this idea of public resource computing? In place of the Oceanstore metadata cluster, there is a central server. In place of the data store, there are machines doing computation. Specifically, mapping on this model of public resource computing is the notion of having one central thing and a bunch of outlying nodes. This is very much a master/slave relationship, though it is a voluntary one. In this relationship, CPU cycles are cheap, but bandwidth is expensive, hence showing why work units are sent infrequently. The storage is in-between--sometimes data is pushed to the clients. When this is done, the resemblance of public resource computing to Oceanstore is stronger.

public resource computing don't need to be very highly reliable because it is used by scientists/ researchers who can bring the system back up, in case it goes down and start again. There are however few measures discussed within SETI like read-only data back-up etc . Compare this to highly reliable systems like ceph or oceanstore , which could recover the data in case of node crashes.

Skype was modelled much like a public resource computing network (before Microsoft took over) as the network would choose super nodes to act as routers. These super nodes would be the machines with higher reliability and better processing powers. After MS' takeover the supernodes have been centralized and the election of supernodes functionality has been removed from the system.

=== Embarrassingly Parallell ===

SETI is an example of "embarrassingly parallel" workload where the problem has inherent nature to lend itself to be divided into work-units and be computed in-parallel without any need to consolidate the results, it is called "embarrassingly parallel" because there is little to no efforts required to distribute the work load in parallel and you don't get much praise for doing it. one more example of "embarrassingly parallel" from the file systems that we have covered so far could be web-indexing in GFS. Any file system that we have discussed so far, which doesnt trust the clients can be modeled to work as public sharing system.

Note: Public resource computing is also very similar to mapreduce, which we will be discussing later in the course. Make sure to keep public resource computing in mind when we reach this.

DistOS 2014W Lecture 16

2014-03-13T02:39:53Z

Gbooth: /* Trust Model and Fault Tolerance */

Public Resource Computing

== Outline for upcoming lectures ==

All the papers that would be covered in upcoming lectures have been posted on Wiki. These papers will be more difficult in comparison to the papers we have covered so far, so we should be prepared to allot more time for studying these papers and come prepared in class. We may abandon the way of discussing the papers in group and instead everyone would ask the questions about what,they did not understand from paper so it would allow us to discuss the technical detail better.
Professor will not be taking the next class, instead our TA would discuss the two papers on how to conduct a literature survey, which should help with our projects.
The rest of the papers will deal with many closely related systems. In particular, we will be looking at distributed hash tables and systems that use distributed hash tables.

== Project proposal==
There were 11 proposals and out of which professor found 4 to be in the state of getting accepted and has graded them 10/10. professor has mailed to everyone with the feedback about the project proposal so that we can incorporate those comments and submit the project proposals by coming Saturday ( the extended deadline). the deadline has been extended so that every one can work out the flaws in their proposal and get the best grades (10/10).
Project Presentation are to be held on 1st and 3rd april. People who got 10/10 should be ready to present on Tuesday as they are ahead and better prepared for it, there should be 6 presentation on Tuesday and rest on Thursday.
Under-grad will have their final exam on 24th April. 24th April is also the date to turn-in the final project report.

== Public Resource Computing ==

The paper assigned for readings were on SETI and BOINC. BOINC is the system SETI is built upon, there are other projects running on the same system like Folding@home etc. In particular, we want to discuss the following:
What is public resource computing? How does public resource computing relate to the various computational models and systems that we have seen this semester? How are they similar in design, purpose, and technologies? How is it different?

The main purpose of public resource computing was to have a universally accessible, easy-to-use, way of sharing resources. This is interesting as it differs from some of the systems we have looked at that deal with the sharing of information rather than resources.

For computational parallelism, you need a highly parallel problem. SETI@home and folding@home give examples of such problems. In public resource computing, particularly with the BOINC system, you divide the problem into work units. People voluntarily install the clients on their machines, running the program to work on work units that are sent to their clients in return for credits. In the past, it has been institutes, such as universities, running services with other people connecting in to use said service. Public resource computing turns this use case on its head, having the institute (e.g., the university) being the one using the service while other people are contributing to said service voluntarily. In the files systems we have covered so far, people would want access to the files stored in a network system, here a system wants to access people's machines to utilize the processing power of their machine. Since they are contributing voluntarily, how do you make these users care about the system if something were to happen? The gamification of the system causes many users to become invested in the system. People are doing work for credits and those with the most credits are showcased as major contributors. They can also see the amount of resources (e.g., process cycles) they have devoted to the cause on the GUI of the installed client. When the client produces results for the work unit it was processing, it sends the result to the server.

For fault tolerance, such as malicious clients are faulty processors, redundant computing is done. Work units are processed multiple times.
Work units are later taken off of the clients as dictated by the following two cases:
# They receive the number of results, '''n''', for a certain work unit, they take the answer that the majority gave.
# They have transmitted a work unit '''m''' times and have not gotten back the n expected responses.
It should be noted that, in doing this, it is possible that some work units are never processed. The probability of this happening can be reduced by increasing the value of '''m''', though.

=== General Discussion ===
So, given all this, how would we generally define public resource computing/public interest computing? It is essentially using the public as a resource--you are voluntarily giving up your extra compute cycles for projects (this is a little like donating blood--public resource computing is a vampire). Looking at public resource computing like this, we can contrast it with a botnet. What is the difference? Both system are utilizing client machines to perform/aid in some task. The answer: consent. You are consensually contributing to a project rather than being (unknowingly) forced to. Other differences are the ends/resources that you want as well as reliability. With a botnet, you can trust that a higher proportion of your users are following your commands exactly (as they have no idea they are performing them). Whereas, in public resource computing, how can you guarantee that clients are doing what you want?

=== Comparisons ===
Basic Comparison with other File systems , we have covered so far -

# Use-Cases have been turned on their head. In the files systems we have covered so far, People would want access to the files stored in a network system, here a system wants to access people's machines to utilize the processing power of their machine.
# In other file systems it was about many clients sharing the data, here it is more about sharing the processing power. In Folding@home, the system can store some of its data at client's storage but that is not the public resource computing's main focus.
# It is nothing like systems like OceanStore where there is no centralized authority, in BOINC the master/slave relation between the centralized server and the clients installed across users' machine can still be visualized and it is more like GFS in that sense because GFS also had a centralized metadata server.
# Public resource systems are like BOTNETs but people install these clients with consent and there is no need for communication between the clients ( it is not peer to peer network). It could be made to communicate at peer to peer level but it would risk security as clients are not trusted in the network

=== Trust Model and Fault Tolerance ===

In this central model, you have a central resource and distribute work to clients who proess the work and send back results. Once they do, you can send them more work. In this model, can you trust the client to complete the computation successfully? The answer is not necessarily--there could be untrustworthy clients sending back rubbish answers.

So, how does SETI address the questions of fault tolerance ? They use replication for reliability and redundant computing. Work units are assigned to multiple clients and the results that are returned to server can be analyzed to find the outliers in order to detect the malicious users but that addresses the situations of fault tolerance from client perspective.

However, SETI has a centralized server, which can go down and when it does, it uses exponential back off to push back the clients and ask them to wait before sending the result again. But, whenever a server comes back up many clients may try to access the server at once and may crash the server once again--essentially, the server will have manufactured its own DDOS attack due to the server's own inadequacies.The Exponential back-off approach is similar to the one adopted in resolving the TCP congestion. It can be noted that there is almost no reliability engineering here, though. These are just standard servers running with one backup that is manually failed over to. This can give an idea of how asymmetric the relationship is.

One reason that this might be is to look at the actual service and who is running it. Reliability for a service is high when a high amount of people use the service and, hence, would be upset were the service to go down. In this case, it's the university using the service and clients are helping out by providing resources. If the service goes down, it is the university's fault and they can individually deal with it.

The idea of redundancy relates to Oceanstore a little, but how would Oceanstore map onto this idea of public resource computing? In place of the Oceanstore metadata cluster, there is a central server. In place of the data store, there are machines doing computation. Specifically, mapping on this model of public resource computing is the notion of having one central thing and a bunch of outlying nodes. This is very much a master/slave relationship, though it is a voluntary one. In this relationship, CPU cycles are cheap, but bandwidth is expensive, hence showing why work units are sent infrequently. The storage is in-between--sometimes data is pushed to the clients. When this is done, the resemblance of public resource computing to Oceanstore is stronger.

public resource computing don't need to be very highly reliable because it is used by scientists/ researchers who can bring the system back up, in case it goes down and start again. There are however few measures discussed within SETI like read-only data back-up etc . Compare this to highly reliable systems like ceph or oceanstore , which could recover the data in case of node crashes.

Skype was modelled much like a public resource computing network (before Microsoft took over) as the network would choose super nodes to act as routers. These super nodes would be the machines with higher reliability and better processing powers. After MS' takeover the supernodes have been centralized and the election of supernodes functionality has been removed from the system.

=== Embarrassingly Parallell ===

SETI is an example of "embarrassingly parallel" workload where the problem has inherent nature to lend itself to be divided into work-units and be computed in-parallel without any need to consolidate the results, it is called "embarrassingly parallel" because there is little to no efforts required to distribute the work load in parallel and you don't get much praise for doing it. one more example of "embarrassingly parallel" from the file systems that we have covered so far could be web-indexing in GFS. Any file system that we have discussed so far, which doesnt trust the clients can be modeled to work as public sharing system.

Note: Public resource computing is also very similar to mapreduce, which we will be discussing later in the course. Make sure to keep public resource computing in mind when we reach this.

DistOS 2014W Lecture 16

2014-03-12T19:37:30Z

Gbooth: /* Trust Model and Fault Tolerance */

Public Resource Computing

== Outline for upcoming lectures ==

All the papers that would be covered in upcoming lectures have been posted on Wiki. These papers will be more difficult in comparison to the papers we have covered so far, so we should be prepared to allot more time for studying these papers and come prepared in class. We may abandon the way of discussing the papers in group and instead everyone would ask the questions about what,they did not understand from paper so it would allow us to discuss the technical detail better.
Professor will not be taking the next class, instead our TA would discuss the two papers on how to conduct a literature survey, which should help with our projects.
The rest of the papers will deal with many closely related systems. In particular, we will be looking at distributed hash tables and systems that use distributed hash tables.

== Project proposal==
There were 11 proposals and out of which professor found 4 to be in the state of getting accepted and has graded them 10/10. professor has mailed to everyone with the feedback about the project proposal so that we can incorporate those comments and submit the project proposals by coming Saturday ( the extended deadline). the deadline has been extended so that every one can work out the flaws in their proposal and get the best grades (10/10).
Project Presentation are to be held on 1st and 3rd april. People who got 10/10 should be ready to present on Tuesday as they are ahead and better prepared for it, there should be 6 presentation on Tuesday and rest on Thursday.
Under-grad will have their final exam on 24th April. 24th April is also the date to turn-in the final project report.

== Public Resource Computing ==

The paper assigned for readings were on SETI and BOINC. BOINC is the system SETI is built upon, there are other projects running on the same system like Folding@home etc. In particular, we want to discuss the following:
What is public resource computing? How does public resource computing relate to the various computational models and systems that we have seen this semester? How are they similar in design, purpose, and technologies? How is it different?

The main purpose of public resource computing was to have a universally accessible, easy-to-use, way of sharing resources. This is interesting as it differs from some of the systems we have looked at that deal with the sharing of information rather than resources.

For computational parallelism, you need a highly parallel problem. SETI@home and folding@home give examples of such problems. In public resource computing, particularly with the BOINC system, you divide the problem into work units. People voluntarily install the clients on their machines, running the program to work on work units that are sent to their clients in return for credits. In the past, it has been institutes, such as universities, running services with other people connecting in to use said service. Public resource computing turns this use case on its head, having the institute (e.g., the university) being the one using the service while other people are contributing to said service voluntarily. In the files systems we have covered so far, people would want access to the files stored in a network system, here a system wants to access people's machines to utilize the processing power of their machine. Since they are contributing voluntarily, how do you make these users care about the system if something were to happen? The gamification of the system causes many users to become invested in the system. People are doing work for credits and those with the most credits are showcased as major contributors. They can also see the amount of resources (e.g., process cycles) they have devoted to the cause on the GUI of the installed client. When the client produces results for the work unit it was processing, it sends the result to the server.

For fault tolerance, such as malicious clients are faulty processors, redundant computing is done. Work units are processed multiple times.
Work units are later taken off of the clients as dictated by the following two cases:
# They receive the number of results, '''n''', for a certain work unit, they take the answer that the majority gave.
# They have transmitted a work unit '''m''' times and have not gotten back the n expected responses.
It should be noted that, in doing this, it is possible that some work units are never processed. The probability of this happening can be reduced by increasing the value of '''m''', though.

=== General Discussion ===
So, given all this, how would we generally define public resource computing/public interest computing? It is essentially using the public as a resource--you are voluntarily giving up your extra compute cycles for projects (this is a little like donating blood--public resource computing is a vampire). Looking at public resource computing like this, we can contrast it with a botnet. What is the difference? Both system are utilizing client machines to perform/aid in some task. The answer: consent. You are consensually contributing to a project rather than being (unknowingly) forced to. Other differences are the ends/resources that you want as well as reliability. With a botnet, you can trust that a higher proportion of your users are following your commands exactly (as they have no idea they are performing them). Whereas, in public resource computing, how can you guarantee that clients are doing what you want?

=== Comparisons ===
Basic Comparison with other File systems , we have covered so far -

# Use-Cases have been turned on their head. In the files systems we have covered so far, People would want access to the files stored in a network system, here a system wants to access people's machines to utilize the processing power of their machine.
# In other file systems it was about many clients sharing the data, here it is more about sharing the processing power. In Folding@home, the system can store some of its data at client's storage but that is not the public resource computing's main focus.
# It is nothing like systems like OceanStore where there is no centralized authority, in BOINC the master/slave relation between the centralized server and the clients installed across users' machine can still be visualized and it is more like GFS in that sense because GFS also had a centralized metadata server.
# Public resource systems are like BOTNETs but people install these clients with consent and there is no need for communication between the clients ( it is not peer to peer network). It could be made to communicate at peer to peer level but it would risk security as clients are not trusted in the network

=== Trust Model and Fault Tolerance ===

Reliability - How does SETI address the questions of fault tolerance ? They use replication for reliability, work units are assigned to multiple clients and the results that are returned to server can be analyzed to find the outliers in order to detect the malicious users but that addresses the situations of fault tolerance from client perspective. SETI has a centralized server, which can go down and when it does, it uses exponential back off mechanism to push back the clients and ask them to wait before sending the result again but whenever a server comes back up many clients may try to access the server at once and may crash the server once again, this may cause the ddos manufactured by the server's own inadequacies.The Exponential backup approach is similar to the one adopted in resolving the TCP congestion.
public resource computing don't need to be very highly reliable because it is used by scientists/ researchers who can bring the system back up, in case it goes down and start again. There are however few measures discussed within SETI like read-only data back-up etc . Compare this to highly reliable systems like ceph or oceanstore , which could recover the data in case of node crashes.

Skype was modelled much like a public resource computing network (before Microsoft took over) as the network would choose super nodes to act as routers. These super nodes would be the machines with higher reliability and better processing powers. After MS' takeover the supernodes have been centralized and the election of supernodes functionality has been removed from the system.

=== Embarrassingly Parallell ===

SETI is an example of "embarrassingly parallel" workload where the problem has inherent nature to lend itself to be divided into work-units and be computed in-parallel without any need to consolidate the results, it is called "embarrassingly parallel" because there is little to no efforts required to distribute the work load in parallel and you don't get much praise for doing it. one more example of "embarrassingly parallel" from the file systems that we have covered so far could be web-indexing in GFS. Any file system that we have discussed so far, which doesnt trust the clients can be modeled to work as public sharing system.

Note: Public resource computing is also very similar to mapreduce, which we will be discussing later in the course. Make sure to keep public resource computing in mind when we reach this.

DistOS 2014W Lecture 16

2014-03-12T19:37:02Z

Gbooth: /* Comparisons */

Public Resource Computing

== Outline for upcoming lectures ==

All the papers that would be covered in upcoming lectures have been posted on Wiki. These papers will be more difficult in comparison to the papers we have covered so far, so we should be prepared to allot more time for studying these papers and come prepared in class. We may abandon the way of discussing the papers in group and instead everyone would ask the questions about what,they did not understand from paper so it would allow us to discuss the technical detail better.
Professor will not be taking the next class, instead our TA would discuss the two papers on how to conduct a literature survey, which should help with our projects.
The rest of the papers will deal with many closely related systems. In particular, we will be looking at distributed hash tables and systems that use distributed hash tables.

== Project proposal==
There were 11 proposals and out of which professor found 4 to be in the state of getting accepted and has graded them 10/10. professor has mailed to everyone with the feedback about the project proposal so that we can incorporate those comments and submit the project proposals by coming Saturday ( the extended deadline). the deadline has been extended so that every one can work out the flaws in their proposal and get the best grades (10/10).
Project Presentation are to be held on 1st and 3rd april. People who got 10/10 should be ready to present on Tuesday as they are ahead and better prepared for it, there should be 6 presentation on Tuesday and rest on Thursday.
Under-grad will have their final exam on 24th April. 24th April is also the date to turn-in the final project report.

== Public Resource Computing ==

The paper assigned for readings were on SETI and BOINC. BOINC is the system SETI is built upon, there are other projects running on the same system like Folding@home etc. In particular, we want to discuss the following:
What is public resource computing? How does public resource computing relate to the various computational models and systems that we have seen this semester? How are they similar in design, purpose, and technologies? How is it different?

The main purpose of public resource computing was to have a universally accessible, easy-to-use, way of sharing resources. This is interesting as it differs from some of the systems we have looked at that deal with the sharing of information rather than resources.

For computational parallelism, you need a highly parallel problem. SETI@home and folding@home give examples of such problems. In public resource computing, particularly with the BOINC system, you divide the problem into work units. People voluntarily install the clients on their machines, running the program to work on work units that are sent to their clients in return for credits. In the past, it has been institutes, such as universities, running services with other people connecting in to use said service. Public resource computing turns this use case on its head, having the institute (e.g., the university) being the one using the service while other people are contributing to said service voluntarily. In the files systems we have covered so far, people would want access to the files stored in a network system, here a system wants to access people's machines to utilize the processing power of their machine. Since they are contributing voluntarily, how do you make these users care about the system if something were to happen? The gamification of the system causes many users to become invested in the system. People are doing work for credits and those with the most credits are showcased as major contributors. They can also see the amount of resources (e.g., process cycles) they have devoted to the cause on the GUI of the installed client. When the client produces results for the work unit it was processing, it sends the result to the server.

For fault tolerance, such as malicious clients are faulty processors, redundant computing is done. Work units are processed multiple times.
Work units are later taken off of the clients as dictated by the following two cases:
# They receive the number of results, '''n''', for a certain work unit, they take the answer that the majority gave.
# They have transmitted a work unit '''m''' times and have not gotten back the n expected responses.
It should be noted that, in doing this, it is possible that some work units are never processed. The probability of this happening can be reduced by increasing the value of '''m''', though.

=== General Discussion ===
So, given all this, how would we generally define public resource computing/public interest computing? It is essentially using the public as a resource--you are voluntarily giving up your extra compute cycles for projects (this is a little like donating blood--public resource computing is a vampire). Looking at public resource computing like this, we can contrast it with a botnet. What is the difference? Both system are utilizing client machines to perform/aid in some task. The answer: consent. You are consensually contributing to a project rather than being (unknowingly) forced to. Other differences are the ends/resources that you want as well as reliability. With a botnet, you can trust that a higher proportion of your users are following your commands exactly (as they have no idea they are performing them). Whereas, in public resource computing, how can you guarantee that clients are doing what you want?

=== Comparisons ===
Basic Comparison with other File systems , we have covered so far -

# Use-Cases have been turned on their head. In the files systems we have covered so far, People would want access to the files stored in a network system, here a system wants to access people's machines to utilize the processing power of their machine.
# In other file systems it was about many clients sharing the data, here it is more about sharing the processing power. In Folding@home, the system can store some of its data at client's storage but that is not the public resource computing's main focus.
# It is nothing like systems like OceanStore where there is no centralized authority, in BOINC the master/slave relation between the centralized server and the clients installed across users' machine can still be visualized and it is more like GFS in that sense because GFS also had a centralized metadata server.
# Public resource systems are like BOTNETs but people install these clients with consent and there is no need for communication between the clients ( it is not peer to peer network). It could be made to communicate at peer to peer level but it would risk security as clients are not trusted in the network

=== Trust Model and Fault Tolerance ===

Reliability - How does SETI address the questions of fault tolerance ? They use replication for reliability, work units are assigned to multiple clients and the results that are returned to server can be analyzed to find the outliers in order to detect the malicious users but that addresses the situations of fault tolerance from client perspective. SETI has a centralized server, which can go down and when it does, it uses exponential back off mechanism to push back the clients and ask them to wait before sending the result again but whenever a server comes back up many clients may try to access the server at once and may crash the server once again, this may cause the ddos manufactured by the server's own inadequacies.The Exponential backup approach is similar to the one adopted in resolving the TCP congestion.
public resource computing don't need to be very highly reliable because it is used by scientists/ researchers who can bring the system back up, in case it goes down and start again. There are however few measures discussed within SETI like read-only data back-up etc . Compare this to highly reliable systems like ceph or oceanstore , which could recover the data in case of node crashes.

Skype was modelled much like a public resource computing network (before Microsoft took over) as the network would choose super nodes to act as routers. These super nodes would be the machines with higher reliability and better processing powers. After MS' takeover the supernodes have been centralized and the election of supernodes functionality has been removed from the system.

SETI is an example of "embarrassingly parallel" workload where the problem has inherent nature to lend itself to be divided into work-units and be computed in-parallel without any need to consolidate the results, it is called "embarrassingly parallel" because there is little to no efforts required to distribute the work load in parallel and you don't get much praise for doing it. one more example of "embarrassingly parallel" from the file systems that we have covered so far could be web-indexing in GFS. Any file system that we have discussed so far, which doesnt trust the clients can be modeled to work as public sharing system.

Note: Public resource computing is also very similar to mapreduce, which we will be discussing later in the course. Make sure to keep public resource computing in mind when we reach this.

DistOS 2014W Lecture 16

2014-03-12T19:36:41Z

Gbooth: /* Public Resource Computing */

Public Resource Computing

== Outline for upcoming lectures ==

All the papers that would be covered in upcoming lectures have been posted on Wiki. These papers will be more difficult in comparison to the papers we have covered so far, so we should be prepared to allot more time for studying these papers and come prepared in class. We may abandon the way of discussing the papers in group and instead everyone would ask the questions about what,they did not understand from paper so it would allow us to discuss the technical detail better.
Professor will not be taking the next class, instead our TA would discuss the two papers on how to conduct a literature survey, which should help with our projects.
The rest of the papers will deal with many closely related systems. In particular, we will be looking at distributed hash tables and systems that use distributed hash tables.

== Project proposal==
There were 11 proposals and out of which professor found 4 to be in the state of getting accepted and has graded them 10/10. professor has mailed to everyone with the feedback about the project proposal so that we can incorporate those comments and submit the project proposals by coming Saturday ( the extended deadline). the deadline has been extended so that every one can work out the flaws in their proposal and get the best grades (10/10).
Project Presentation are to be held on 1st and 3rd april. People who got 10/10 should be ready to present on Tuesday as they are ahead and better prepared for it, there should be 6 presentation on Tuesday and rest on Thursday.
Under-grad will have their final exam on 24th April. 24th April is also the date to turn-in the final project report.

== Public Resource Computing ==

The paper assigned for readings were on SETI and BOINC. BOINC is the system SETI is built upon, there are other projects running on the same system like Folding@home etc. In particular, we want to discuss the following:
What is public resource computing? How does public resource computing relate to the various computational models and systems that we have seen this semester? How are they similar in design, purpose, and technologies? How is it different?

The main purpose of public resource computing was to have a universally accessible, easy-to-use, way of sharing resources. This is interesting as it differs from some of the systems we have looked at that deal with the sharing of information rather than resources.

For computational parallelism, you need a highly parallel problem. SETI@home and folding@home give examples of such problems. In public resource computing, particularly with the BOINC system, you divide the problem into work units. People voluntarily install the clients on their machines, running the program to work on work units that are sent to their clients in return for credits. In the past, it has been institutes, such as universities, running services with other people connecting in to use said service. Public resource computing turns this use case on its head, having the institute (e.g., the university) being the one using the service while other people are contributing to said service voluntarily. In the files systems we have covered so far, people would want access to the files stored in a network system, here a system wants to access people's machines to utilize the processing power of their machine. Since they are contributing voluntarily, how do you make these users care about the system if something were to happen? The gamification of the system causes many users to become invested in the system. People are doing work for credits and those with the most credits are showcased as major contributors. They can also see the amount of resources (e.g., process cycles) they have devoted to the cause on the GUI of the installed client. When the client produces results for the work unit it was processing, it sends the result to the server.

For fault tolerance, such as malicious clients are faulty processors, redundant computing is done. Work units are processed multiple times.
Work units are later taken off of the clients as dictated by the following two cases:
# They receive the number of results, '''n''', for a certain work unit, they take the answer that the majority gave.
# They have transmitted a work unit '''m''' times and have not gotten back the n expected responses.
It should be noted that, in doing this, it is possible that some work units are never processed. The probability of this happening can be reduced by increasing the value of '''m''', though.

=== General Discussion ===
So, given all this, how would we generally define public resource computing/public interest computing? It is essentially using the public as a resource--you are voluntarily giving up your extra compute cycles for projects (this is a little like donating blood--public resource computing is a vampire). Looking at public resource computing like this, we can contrast it with a botnet. What is the difference? Both system are utilizing client machines to perform/aid in some task. The answer: consent. You are consensually contributing to a project rather than being (unknowingly) forced to. Other differences are the ends/resources that you want as well as reliability. With a botnet, you can trust that a higher proportion of your users are following your commands exactly (as they have no idea they are performing them). Whereas, in public resource computing, how can you guarantee that clients are doing what you want?

=== Comparisons ===
Basic Comparison with other File systems , we have covered so far -

1) Use-Cases have been turned on their head. In the files systems we have covered so far, People would want access to the files stored in a network system, here a system wants to access people's machines to utilize the processing power of their machine.
2) In other file systems it was about many clients sharing the data, here it is more about sharing the processing power. In Folding@home, the system can store some of its data at client's storage but that is not the public resource computing's main focus.
3) It is nothing like systems like OceanStore where there is no centralized authority, in BOINC the master/slave relation between the centralized server and the clients installed across users' machine can still be visualized and it is more like GFS in that sense because GFS also had a centralized metadata server.
4) Public resource systems are like BOTNETs but people install these clients with consent and there is no need for communication between the clients ( it is not peer to peer network). It could be made to communicate at peer to peer level but it would risk security as clients are not trusted in the network

=== Trust Model and Fault Tolerance ===

Reliability - How does SETI address the questions of fault tolerance ? They use replication for reliability, work units are assigned to multiple clients and the results that are returned to server can be analyzed to find the outliers in order to detect the malicious users but that addresses the situations of fault tolerance from client perspective. SETI has a centralized server, which can go down and when it does, it uses exponential back off mechanism to push back the clients and ask them to wait before sending the result again but whenever a server comes back up many clients may try to access the server at once and may crash the server once again, this may cause the ddos manufactured by the server's own inadequacies.The Exponential backup approach is similar to the one adopted in resolving the TCP congestion.
public resource computing don't need to be very highly reliable because it is used by scientists/ researchers who can bring the system back up, in case it goes down and start again. There are however few measures discussed within SETI like read-only data back-up etc . Compare this to highly reliable systems like ceph or oceanstore , which could recover the data in case of node crashes.

Skype was modelled much like a public resource computing network (before Microsoft took over) as the network would choose super nodes to act as routers. These super nodes would be the machines with higher reliability and better processing powers. After MS' takeover the supernodes have been centralized and the election of supernodes functionality has been removed from the system.

SETI is an example of "embarrassingly parallel" workload where the problem has inherent nature to lend itself to be divided into work-units and be computed in-parallel without any need to consolidate the results, it is called "embarrassingly parallel" because there is little to no efforts required to distribute the work load in parallel and you don't get much praise for doing it. one more example of "embarrassingly parallel" from the file systems that we have covered so far could be web-indexing in GFS. Any file system that we have discussed so far, which doesnt trust the clients can be modeled to work as public sharing system.

Note: Public resource computing is also very similar to mapreduce, which we will be discussing later in the course. Make sure to keep public resource computing in mind when we reach this.

DistOS 2014W Lecture 16

2014-03-12T19:34:46Z

Gbooth:

Public Resource Computing

== Outline for upcoming lectures ==

All the papers that would be covered in upcoming lectures have been posted on Wiki. These papers will be more difficult in comparison to the papers we have covered so far, so we should be prepared to allot more time for studying these papers and come prepared in class. We may abandon the way of discussing the papers in group and instead everyone would ask the questions about what,they did not understand from paper so it would allow us to discuss the technical detail better.
Professor will not be taking the next class, instead our TA would discuss the two papers on how to conduct a literature survey, which should help with our projects.
The rest of the papers will deal with many closely related systems. In particular, we will be looking at distributed hash tables and systems that use distributed hash tables.

== Project proposal==
There were 11 proposals and out of which professor found 4 to be in the state of getting accepted and has graded them 10/10. professor has mailed to everyone with the feedback about the project proposal so that we can incorporate those comments and submit the project proposals by coming Saturday ( the extended deadline). the deadline has been extended so that every one can work out the flaws in their proposal and get the best grades (10/10).
Project Presentation are to be held on 1st and 3rd april. People who got 10/10 should be ready to present on Tuesday as they are ahead and better prepared for it, there should be 6 presentation on Tuesday and rest on Thursday.
Under-grad will have their final exam on 24th April. 24th April is also the date to turn-in the final project report.

== Public Resource Computing ==

The paper assigned for readings were on SETI and BOINC. BOINC is the system SETI is built upon, there are other projects running on the same system like Folding@home etc. In particular, we want to discuss the following:
What is public resource computing? How does public resource computing relate to the various computational models and systems that we have seen this semester? How are they similar in design, purpose, and technologies? How is it different?

The main purpose of public resource computing was to have a universally accessible, easy-to-use, way of sharing resources. This is interesting as it differs from some of the systems we have looked at that deal with the sharing of information rather than resources.

For computational parallelism, you need a highly parallel problem. SETI@home and folding@home give examples of such problems. In public resource computing, particularly with the BOINC system, you divide the problem into work units. People voluntarily install the clients on their machines, running the program to work on work units that are sent to their clients in return for credits. In the past, it has been institutes, such as universities, running services with other people connecting in to use said service. Public resource computing turns this use case on its head, having the institute (e.g., the university) being the one using the service while other people are contributing to said service voluntarily. In the files systems we have covered so far, people would want access to the files stored in a network system, here a system wants to access people's machines to utilize the processing power of their machine. Since they are contributing voluntarily, how do you make these users care about the system if something were to happen? The gamification of the system causes many users to become invested in the system. People are doing work for credits and those with the most credits are showcased as major contributors. They can also see the amount of resources (e.g., process cycles) they have devoted to the cause on the GUI of the installed client. When the client produces results for the work unit it was processing, it sends the result to the server.
For fault tolerance, such as malicious clients are faulty processors, redundant computing is done. Work units are processed multiple times.
Work units are later taken off of the clients as dictated by the following two cases:
# They receive the number of results, '''n''', for a certain work unit, they take the answer that the majority gave.
# They have transmitted a work unit '''m''' times and have not gotten back the n expected responses.
It should be noted that, in doing this, it is possible that some work units are never processed. The probability of this happening can be reduced by increasing the value of '''m''', though.

So, given all this, how would we generally define public resource computing/public interest computing? It is essentially using the public as a resource--you are voluntarily giving up your extra compute cycles for projects (this is a little like donating blood--public resource computing is a vampire). Looking at public resource computing like this, we can contrast it with a botnet. What is the difference? Both system are utilizing client machines to perform/aid in some task. The answer: consent. You are consensually contributing to a project rather than being (unknowingly) forced to. Other differences are the ends/resources that you want as well as reliability. With a botnet, you can trust that a higher proportion of your users are following your commands exactly (as they have no idea they are performing them). Whereas, in public resource computing, how can you guarantee that clients are doing what you want?

Basic Comparison with other File systems , we have covered so far -

1) Use-Cases have been turned on their head. In the files systems we have covered so far, People would want access to the files stored in a network system, here a system wants to access people's machines to utilize the processing power of their machine.
2) In other file systems it was about many clients sharing the data, here it is more about sharing the processing power. In Folding@home, the system can store some of its data at client's storage but that is not the public resource computing's main focus.
3) It is nothing like systems like OceanStore where there is no centralized authority, in BOINC the master/slave relation between the centralized server and the clients installed across users' machine can still be visualized and it is more like GFS in that sense because GFS also had a centralized metadata server.
4) Public resource systems are like BOTNETs but people install these clients with consent and there is no need for communication between the clients ( it is not peer to peer network). It could be made to communicate at peer to peer level but it would risk security as clients are not trusted in the network

Reliability - How does SETI address the questions of fault tolerance ? They use replication for reliability, work units are assigned to multiple clients and the results that are returned to server can be analyzed to find the outliers in order to detect the malicious users but that addresses the situations of fault tolerance from client perspective. SETI has a centralized server, which can go down and when it does, it uses exponential back off mechanism to push back the clients and ask them to wait before sending the result again but whenever a server comes back up many clients may try to access the server at once and may crash the server once again, this may cause the ddos manufactured by the server's own inadequacies.The Exponential backup approach is similar to the one adopted in resolving the TCP congestion.
public resource computing don't need to be very highly reliable because it is used by scientists/ researchers who can bring the system back up, in case it goes down and start again. There are however few measures discussed within SETI like read-only data back-up etc . Compare this to highly reliable systems like ceph or oceanstore , which could recover the data in case of node crashes.

Skype was modelled much like a public resource computing network (before Microsoft took over) as the network would choose super nodes to act as routers. These super nodes would be the machines with higher reliability and better processing powers. After MS' takeover the supernodes have been centralized and the election of supernodes functionality has been removed from the system.

SETI is an example of "embarrassingly parallel" workload where the problem has inherent nature to lend itself to be divided into work-units and be computed in-parallel without any need to consolidate the results, it is called "embarrassingly parallel" because there is little to no efforts required to distribute the work load in parallel and you don't get much praise for doing it. one more example of "embarrassingly parallel" from the file systems that we have covered so far could be web-indexing in GFS. Any file system that we have discussed so far, which doesnt trust the clients can be modeled to work as public sharing system.

Note: Public resource computing is also very similar to mapreduce, which we will be discussing later in the course. Make sure to keep public resource computing in mind when we reach this.

DistOS 2014W Lecture 14

2014-03-09T15:39:27Z

Gbooth: /* How to read a research paper */

=OceanStore=

==What is the dream?==
The dream was to create a persistent storage system that had high availability and was universally accessibly--a global, ubiquitous persistent data storage solution. OceanStore was meant to be utility managed by multiple parties, with no one party having total control/monopoly over the system. To support the goal of high availability, there was a high amount of redundancy and fault-tolerance. For high persistence, everything was archived--nothing was ever truly deleted. This can be likened to working in version control with "Commits". This is possibly due to the realization that the easier it is to delete things, the easier it is to lose things.

The basic assumption made by the designers of OceanStore, however, was that none of the servers could be trusted. To support this, the system held only opaque/encrypted data. As such, the system could be used for more than files (e.g., for whole databases).

The system utilized nomadic data, meaning that data could be cached anywhere, unlike with NFS and AFS where only specific servers can cache the data.

==Why did the dream die?==

The biggest reason that caused the OceanStore dream to die was the assumption of mistrusting all the actors--everything else they did was right. This assumption, however, caused the system to become needlessly complicated as they had to rebuild ''everything'' to accommodate this assumption. This was also unrealistic as this is not an assumption that is generally made (i.e., it is normally assumed that at least some of the actors can be trusted). Other successful distributed systems are built on a more trusted model. In short, the solution that accommodates untrusted actors assumption is just too expensive.

=== Technology ===
As outlined above, the trust model (read: fundamentally untrusted model) is the most attractive feature which ultimately killed it. The untrusted assumption introduced a huge burden on the system, forcing technical limitations which made OceanStore uncompetitive in comparison to other solutions. It is just much more easy and convenient to trust a given system. It should be noted that every system is compromisable, despite this mistrust.

The public key system also reduces usability--if a user loses their key, they are completely out of luck and would need to acquire a new key. This also means that, if you wanted to remove their access over an object, you would have to re-encrypt the object with a new key and provide that key to said user, who would then have access to the object.

With regards to the security, there is no security mechanism on the server side. The server can not know who is accessing the data. On the economic side, the economic model is unconvincing with the way it is defined. The authors suggest that a collection of companies will host OceanStore servers and consumers will buy capacity (not unlike web-hosting today).

===Use Cases===
A subset of the features outlined for OceanStore already exist. For example, Blackberry and Google offer similar services. These current services are owned by one company, however, not many providers. You can also not sell back your services as a user (e.g., you can't sell your extra storage back to the utility).

==Pond: What insights?==
In short: they actually built it! However, due to the untrusted assumption, they can't assume the use of any infrastructure, causing them to rebuild ''everything''! It was built over the internet with Tapestry (routing) and GUID for object identification (object naming scheme).

==Benchmarks==
In short: the system had really good read speed, really bad write speed.

===Storage overhead===
One general question was how much are they increasing the storage needed to implement their storage model? The answer: a factor of 4.8x the space is needed (you'll have 1/5th the storage). While this is expensive, it does have a good value as your data is backed up, replicated, etc. However, it does cause one to consider how important it is to make an update as you burn more storage space as more updates are made.

===Update performance===
None of the data is mutated--it is diffed and archived. You are essentially creating a new version of an object and then distributing that object.

===Benchmarks in a nutshell===
Absolutely everything is expensive and there is high latency.

==Other stuff==
'''Byzantine fault tolerance'''
* byzantine fault tolerant network replicates the data in such a way that even if m nodes out of total n nodes,in a network,fail, you would still be able to recover the whole data. but as you increase the value of number m, the required network messages to be exchanges also increases, so there is a tradeoff.
* You are assuming certain actors are malicious.
'''Bitcoin'''
* Trusted vs Untrusted.
* It is considered to be untrusted but it takes huge amount of trust when exchanges are made.

==What's worth salvaging from the dream?==
Some of the good things that we can salvage are using spare resources in other locations. It can also be noted that similar routing systems are used in large peer to peer systems.

==How to read a research paper==
# Start with the Introduction to figure out what the problem is.
# See/read through the related work/background for context of the paper.
# Go to the conclusion and focus on the results (i.e., figure out what they actually did).
# Fill in the gaps by reading specific parts of the body.

DistOS 2014W Lecture 14

2014-03-09T15:37:59Z

Gbooth: /* What's worth salvaging from the dream? */

=OceanStore=

==What is the dream?==
The dream was to create a persistent storage system that had high availability and was universally accessibly--a global, ubiquitous persistent data storage solution. OceanStore was meant to be utility managed by multiple parties, with no one party having total control/monopoly over the system. To support the goal of high availability, there was a high amount of redundancy and fault-tolerance. For high persistence, everything was archived--nothing was ever truly deleted. This can be likened to working in version control with "Commits". This is possibly due to the realization that the easier it is to delete things, the easier it is to lose things.

The basic assumption made by the designers of OceanStore, however, was that none of the servers could be trusted. To support this, the system held only opaque/encrypted data. As such, the system could be used for more than files (e.g., for whole databases).

The system utilized nomadic data, meaning that data could be cached anywhere, unlike with NFS and AFS where only specific servers can cache the data.

==Why did the dream die?==

The biggest reason that caused the OceanStore dream to die was the assumption of mistrusting all the actors--everything else they did was right. This assumption, however, caused the system to become needlessly complicated as they had to rebuild ''everything'' to accommodate this assumption. This was also unrealistic as this is not an assumption that is generally made (i.e., it is normally assumed that at least some of the actors can be trusted). Other successful distributed systems are built on a more trusted model. In short, the solution that accommodates untrusted actors assumption is just too expensive.

=== Technology ===
As outlined above, the trust model (read: fundamentally untrusted model) is the most attractive feature which ultimately killed it. The untrusted assumption introduced a huge burden on the system, forcing technical limitations which made OceanStore uncompetitive in comparison to other solutions. It is just much more easy and convenient to trust a given system. It should be noted that every system is compromisable, despite this mistrust.

The public key system also reduces usability--if a user loses their key, they are completely out of luck and would need to acquire a new key. This also means that, if you wanted to remove their access over an object, you would have to re-encrypt the object with a new key and provide that key to said user, who would then have access to the object.

With regards to the security, there is no security mechanism on the server side. The server can not know who is accessing the data. On the economic side, the economic model is unconvincing with the way it is defined. The authors suggest that a collection of companies will host OceanStore servers and consumers will buy capacity (not unlike web-hosting today).

===Use Cases===
A subset of the features outlined for OceanStore already exist. For example, Blackberry and Google offer similar services. These current services are owned by one company, however, not many providers. You can also not sell back your services as a user (e.g., you can't sell your extra storage back to the utility).

==Pond: What insights?==
In short: they actually built it! However, due to the untrusted assumption, they can't assume the use of any infrastructure, causing them to rebuild ''everything''! It was built over the internet with Tapestry (routing) and GUID for object identification (object naming scheme).

==Benchmarks==
In short: the system had really good read speed, really bad write speed.

===Storage overhead===
One general question was how much are they increasing the storage needed to implement their storage model? The answer: a factor of 4.8x the space is needed (you'll have 1/5th the storage). While this is expensive, it does have a good value as your data is backed up, replicated, etc. However, it does cause one to consider how important it is to make an update as you burn more storage space as more updates are made.

===Update performance===
None of the data is mutated--it is diffed and archived. You are essentially creating a new version of an object and then distributing that object.

===Benchmarks in a nutshell===
Absolutely everything is expensive and there is high latency.

==Other stuff==
'''Byzantine fault tolerance'''
* byzantine fault tolerant network replicates the data in such a way that even if m nodes out of total n nodes,in a network,fail, you would still be able to recover the whole data. but as you increase the value of number m, the required network messages to be exchanges also increases, so there is a tradeoff.
* You are assuming certain actors are malicious.
'''Bitcoin'''
* Trusted vs Untrusted.
* It is considered to be untrusted but it takes huge amount of trust when exchanges are made.

==What's worth salvaging from the dream?==
Some of the good things that we can salvage are using spare resources in other locations. It can also be noted that similar routing systems are used in large peer to peer systems.

==How to read a research paper==
* Start with Intro
** Figure out what the problem is
* then see the related work for context
* then go to conclusion. Focus on results.
* then fill in the gaps by reading specific parts of the body

DistOS 2014W Lecture 14

2014-03-09T15:37:09Z

Gbooth: /* Other stuff */

=OceanStore=

==What is the dream?==
The dream was to create a persistent storage system that had high availability and was universally accessibly--a global, ubiquitous persistent data storage solution. OceanStore was meant to be utility managed by multiple parties, with no one party having total control/monopoly over the system. To support the goal of high availability, there was a high amount of redundancy and fault-tolerance. For high persistence, everything was archived--nothing was ever truly deleted. This can be likened to working in version control with "Commits". This is possibly due to the realization that the easier it is to delete things, the easier it is to lose things.

The basic assumption made by the designers of OceanStore, however, was that none of the servers could be trusted. To support this, the system held only opaque/encrypted data. As such, the system could be used for more than files (e.g., for whole databases).

The system utilized nomadic data, meaning that data could be cached anywhere, unlike with NFS and AFS where only specific servers can cache the data.

==Why did the dream die?==

The biggest reason that caused the OceanStore dream to die was the assumption of mistrusting all the actors--everything else they did was right. This assumption, however, caused the system to become needlessly complicated as they had to rebuild ''everything'' to accommodate this assumption. This was also unrealistic as this is not an assumption that is generally made (i.e., it is normally assumed that at least some of the actors can be trusted). Other successful distributed systems are built on a more trusted model. In short, the solution that accommodates untrusted actors assumption is just too expensive.

=== Technology ===
As outlined above, the trust model (read: fundamentally untrusted model) is the most attractive feature which ultimately killed it. The untrusted assumption introduced a huge burden on the system, forcing technical limitations which made OceanStore uncompetitive in comparison to other solutions. It is just much more easy and convenient to trust a given system. It should be noted that every system is compromisable, despite this mistrust.

The public key system also reduces usability--if a user loses their key, they are completely out of luck and would need to acquire a new key. This also means that, if you wanted to remove their access over an object, you would have to re-encrypt the object with a new key and provide that key to said user, who would then have access to the object.

With regards to the security, there is no security mechanism on the server side. The server can not know who is accessing the data. On the economic side, the economic model is unconvincing with the way it is defined. The authors suggest that a collection of companies will host OceanStore servers and consumers will buy capacity (not unlike web-hosting today).

===Use Cases===
A subset of the features outlined for OceanStore already exist. For example, Blackberry and Google offer similar services. These current services are owned by one company, however, not many providers. You can also not sell back your services as a user (e.g., you can't sell your extra storage back to the utility).

==Pond: What insights?==
In short: they actually built it! However, due to the untrusted assumption, they can't assume the use of any infrastructure, causing them to rebuild ''everything''! It was built over the internet with Tapestry (routing) and GUID for object identification (object naming scheme).

==Benchmarks==
In short: the system had really good read speed, really bad write speed.

===Storage overhead===
One general question was how much are they increasing the storage needed to implement their storage model? The answer: a factor of 4.8x the space is needed (you'll have 1/5th the storage). While this is expensive, it does have a good value as your data is backed up, replicated, etc. However, it does cause one to consider how important it is to make an update as you burn more storage space as more updates are made.

===Update performance===
None of the data is mutated--it is diffed and archived. You are essentially creating a new version of an object and then distributing that object.

===Benchmarks in a nutshell===
Absolutely everything is expensive and there is high latency.

==Other stuff==
'''Byzantine fault tolerance'''
* byzantine fault tolerant network replicates the data in such a way that even if m nodes out of total n nodes,in a network,fail, you would still be able to recover the whole data. but as you increase the value of number m, the required network messages to be exchanges also increases, so there is a tradeoff.
* You are assuming certain actors are malicious.
'''Bitcoin'''
* Trusted vs Untrusted.
* It is considered to be untrusted but it takes huge amount of trust when exchanges are made.

==What's worth salvaging from the dream?==
* Using spare resources in other locations.
* Similar routing system are used in large peer to peer systems.

==How to read a research paper==
* Start with Intro
** Figure out what the problem is
* then see the related work for context
* then go to conclusion. Focus on results.
* then fill in the gaps by reading specific parts of the body

DistOS 2014W Lecture 14

2014-03-09T15:36:00Z

Gbooth: /* Benchmarks */

=OceanStore=

==What is the dream?==
The dream was to create a persistent storage system that had high availability and was universally accessibly--a global, ubiquitous persistent data storage solution. OceanStore was meant to be utility managed by multiple parties, with no one party having total control/monopoly over the system. To support the goal of high availability, there was a high amount of redundancy and fault-tolerance. For high persistence, everything was archived--nothing was ever truly deleted. This can be likened to working in version control with "Commits". This is possibly due to the realization that the easier it is to delete things, the easier it is to lose things.

The basic assumption made by the designers of OceanStore, however, was that none of the servers could be trusted. To support this, the system held only opaque/encrypted data. As such, the system could be used for more than files (e.g., for whole databases).

The system utilized nomadic data, meaning that data could be cached anywhere, unlike with NFS and AFS where only specific servers can cache the data.

==Why did the dream die?==

The biggest reason that caused the OceanStore dream to die was the assumption of mistrusting all the actors--everything else they did was right. This assumption, however, caused the system to become needlessly complicated as they had to rebuild ''everything'' to accommodate this assumption. This was also unrealistic as this is not an assumption that is generally made (i.e., it is normally assumed that at least some of the actors can be trusted). Other successful distributed systems are built on a more trusted model. In short, the solution that accommodates untrusted actors assumption is just too expensive.

=== Technology ===
As outlined above, the trust model (read: fundamentally untrusted model) is the most attractive feature which ultimately killed it. The untrusted assumption introduced a huge burden on the system, forcing technical limitations which made OceanStore uncompetitive in comparison to other solutions. It is just much more easy and convenient to trust a given system. It should be noted that every system is compromisable, despite this mistrust.

The public key system also reduces usability--if a user loses their key, they are completely out of luck and would need to acquire a new key. This also means that, if you wanted to remove their access over an object, you would have to re-encrypt the object with a new key and provide that key to said user, who would then have access to the object.

With regards to the security, there is no security mechanism on the server side. The server can not know who is accessing the data. On the economic side, the economic model is unconvincing with the way it is defined. The authors suggest that a collection of companies will host OceanStore servers and consumers will buy capacity (not unlike web-hosting today).

===Use Cases===
A subset of the features outlined for OceanStore already exist. For example, Blackberry and Google offer similar services. These current services are owned by one company, however, not many providers. You can also not sell back your services as a user (e.g., you can't sell your extra storage back to the utility).

==Pond: What insights?==
In short: they actually built it! However, due to the untrusted assumption, they can't assume the use of any infrastructure, causing them to rebuild ''everything''! It was built over the internet with Tapestry (routing) and GUID for object identification (object naming scheme).

==Benchmarks==
In short: the system had really good read speed, really bad write speed.

===Storage overhead===
One general question was how much are they increasing the storage needed to implement their storage model? The answer: a factor of 4.8x the space is needed (you'll have 1/5th the storage). While this is expensive, it does have a good value as your data is backed up, replicated, etc. However, it does cause one to consider how important it is to make an update as you burn more storage space as more updates are made.

===Update performance===
None of the data is mutated--it is diffed and archived. You are essentially creating a new version of an object and then distributing that object.

===Benchmarks in a nutshell===
Absolutely everything is expensive and there is high latency.

==Other stuff==
* Byzantine fault tolerance
** byzantine fault tolerant network replicates the data in such a way that even if m nodes out of total n nodes,in a network,fail, you would still be able to recover the whole data. but as you increase the value of number m, the required network messages to be exchanges also increases, so there is a tradeoff.
** Assuming certain actors are malicious
* Bitcoin
** Trusted vs Untrusted.
** It is considered to be untrusted but it takes huge amount of trust when exchanges are made.

==What's worth salvaging from the dream?==
* Using spare resources in other locations.
* Similar routing system are used in large peer to peer systems.

==How to read a research paper==
* Start with Intro
** Figure out what the problem is
* then see the related work for context
* then go to conclusion. Focus on results.
* then fill in the gaps by reading specific parts of the body

DistOS 2014W Lecture 14

2014-03-09T15:33:18Z

Gbooth: /* Pond: What insights? */

=OceanStore=

==What is the dream?==
The dream was to create a persistent storage system that had high availability and was universally accessibly--a global, ubiquitous persistent data storage solution. OceanStore was meant to be utility managed by multiple parties, with no one party having total control/monopoly over the system. To support the goal of high availability, there was a high amount of redundancy and fault-tolerance. For high persistence, everything was archived--nothing was ever truly deleted. This can be likened to working in version control with "Commits". This is possibly due to the realization that the easier it is to delete things, the easier it is to lose things.

The basic assumption made by the designers of OceanStore, however, was that none of the servers could be trusted. To support this, the system held only opaque/encrypted data. As such, the system could be used for more than files (e.g., for whole databases).

The system utilized nomadic data, meaning that data could be cached anywhere, unlike with NFS and AFS where only specific servers can cache the data.

==Why did the dream die?==

The biggest reason that caused the OceanStore dream to die was the assumption of mistrusting all the actors--everything else they did was right. This assumption, however, caused the system to become needlessly complicated as they had to rebuild ''everything'' to accommodate this assumption. This was also unrealistic as this is not an assumption that is generally made (i.e., it is normally assumed that at least some of the actors can be trusted). Other successful distributed systems are built on a more trusted model. In short, the solution that accommodates untrusted actors assumption is just too expensive.

=== Technology ===
As outlined above, the trust model (read: fundamentally untrusted model) is the most attractive feature which ultimately killed it. The untrusted assumption introduced a huge burden on the system, forcing technical limitations which made OceanStore uncompetitive in comparison to other solutions. It is just much more easy and convenient to trust a given system. It should be noted that every system is compromisable, despite this mistrust.

The public key system also reduces usability--if a user loses their key, they are completely out of luck and would need to acquire a new key. This also means that, if you wanted to remove their access over an object, you would have to re-encrypt the object with a new key and provide that key to said user, who would then have access to the object.

With regards to the security, there is no security mechanism on the server side. The server can not know who is accessing the data. On the economic side, the economic model is unconvincing with the way it is defined. The authors suggest that a collection of companies will host OceanStore servers and consumers will buy capacity (not unlike web-hosting today).

===Use Cases===
A subset of the features outlined for OceanStore already exist. For example, Blackberry and Google offer similar services. These current services are owned by one company, however, not many providers. You can also not sell back your services as a user (e.g., you can't sell your extra storage back to the utility).

==Pond: What insights?==
In short: they actually built it! However, due to the untrusted assumption, they can't assume the use of any infrastructure, causing them to rebuild ''everything''! It was built over the internet with Tapestry (routing) and GUID for object identification (object naming scheme).

==Benchmarks==
* Really good read speed, really bad write speed.

===Storage overhead===
* How much are they increasing the storage needed to implement their storage model.
* Factor of 4.8x the space needed (you'll have 1/5th the storage)
* Expensive, but good value (data is backed up, replicated, etc..)
* Considerations of importance before making an update
** burn more storage space as more updates are made

===Update performance===
* No data is mutated. It is diffed and archived.
* Creating a new version of an object and distributing that object.

===Benchmarks in a nutshell===
* Everything is expensive!
* High latency

==Other stuff==
* Byzantine fault tolerance
** byzantine fault tolerant network replicates the data in such a way that even if m nodes out of total n nodes,in a network,fail, you would still be able to recover the whole data. but as you increase the value of number m, the required network messages to be exchanges also increases, so there is a tradeoff.
** Assuming certain actors are malicious
* Bitcoin
** Trusted vs Untrusted.
** It is considered to be untrusted but it takes huge amount of trust when exchanges are made.

==What's worth salvaging from the dream?==
* Using spare resources in other locations.
* Similar routing system are used in large peer to peer systems.

==How to read a research paper==
* Start with Intro
** Figure out what the problem is
* then see the related work for context
* then go to conclusion. Focus on results.
* then fill in the gaps by reading specific parts of the body

DistOS 2014W Lecture 14

2014-03-09T15:32:03Z

Gbooth: /* Use Cases */

=OceanStore=

==What is the dream?==
The dream was to create a persistent storage system that had high availability and was universally accessibly--a global, ubiquitous persistent data storage solution. OceanStore was meant to be utility managed by multiple parties, with no one party having total control/monopoly over the system. To support the goal of high availability, there was a high amount of redundancy and fault-tolerance. For high persistence, everything was archived--nothing was ever truly deleted. This can be likened to working in version control with "Commits". This is possibly due to the realization that the easier it is to delete things, the easier it is to lose things.

The basic assumption made by the designers of OceanStore, however, was that none of the servers could be trusted. To support this, the system held only opaque/encrypted data. As such, the system could be used for more than files (e.g., for whole databases).

The system utilized nomadic data, meaning that data could be cached anywhere, unlike with NFS and AFS where only specific servers can cache the data.

==Why did the dream die?==

The biggest reason that caused the OceanStore dream to die was the assumption of mistrusting all the actors--everything else they did was right. This assumption, however, caused the system to become needlessly complicated as they had to rebuild ''everything'' to accommodate this assumption. This was also unrealistic as this is not an assumption that is generally made (i.e., it is normally assumed that at least some of the actors can be trusted). Other successful distributed systems are built on a more trusted model. In short, the solution that accommodates untrusted actors assumption is just too expensive.

=== Technology ===
As outlined above, the trust model (read: fundamentally untrusted model) is the most attractive feature which ultimately killed it. The untrusted assumption introduced a huge burden on the system, forcing technical limitations which made OceanStore uncompetitive in comparison to other solutions. It is just much more easy and convenient to trust a given system. It should be noted that every system is compromisable, despite this mistrust.

The public key system also reduces usability--if a user loses their key, they are completely out of luck and would need to acquire a new key. This also means that, if you wanted to remove their access over an object, you would have to re-encrypt the object with a new key and provide that key to said user, who would then have access to the object.

With regards to the security, there is no security mechanism on the server side. The server can not know who is accessing the data. On the economic side, the economic model is unconvincing with the way it is defined. The authors suggest that a collection of companies will host OceanStore servers and consumers will buy capacity (not unlike web-hosting today).

===Use Cases===
A subset of the features outlined for OceanStore already exist. For example, Blackberry and Google offer similar services. These current services are owned by one company, however, not many providers. You can also not sell back your services as a user (e.g., you can't sell your extra storage back to the utility).

==Pond: What insights?==

* They actually built it.
* Can't assume the use of any infrastructure, so they rebuild everything!
** Built over the internet.
** Tapestry (routing).
** GUID for object indentification. Object naming scheme.

==Benchmarks==
* Really good read speed, really bad write speed.

===Storage overhead===
* How much are they increasing the storage needed to implement their storage model.
* Factor of 4.8x the space needed (you'll have 1/5th the storage)
* Expensive, but good value (data is backed up, replicated, etc..)
* Considerations of importance before making an update
** burn more storage space as more updates are made

===Update performance===
* No data is mutated. It is diffed and archived.
* Creating a new version of an object and distributing that object.

===Benchmarks in a nutshell===
* Everything is expensive!
* High latency

==Other stuff==
* Byzantine fault tolerance
** byzantine fault tolerant network replicates the data in such a way that even if m nodes out of total n nodes,in a network,fail, you would still be able to recover the whole data. but as you increase the value of number m, the required network messages to be exchanges also increases, so there is a tradeoff.
** Assuming certain actors are malicious
* Bitcoin
** Trusted vs Untrusted.
** It is considered to be untrusted but it takes huge amount of trust when exchanges are made.

==What's worth salvaging from the dream?==
* Using spare resources in other locations.
* Similar routing system are used in large peer to peer systems.

==How to read a research paper==
* Start with Intro
** Figure out what the problem is
* then see the related work for context
* then go to conclusion. Focus on results.
* then fill in the gaps by reading specific parts of the body

DistOS 2014W Lecture 14

2014-03-09T15:30:36Z

Gbooth: /* Technology */

=OceanStore=

==What is the dream?==
The dream was to create a persistent storage system that had high availability and was universally accessibly--a global, ubiquitous persistent data storage solution. OceanStore was meant to be utility managed by multiple parties, with no one party having total control/monopoly over the system. To support the goal of high availability, there was a high amount of redundancy and fault-tolerance. For high persistence, everything was archived--nothing was ever truly deleted. This can be likened to working in version control with "Commits". This is possibly due to the realization that the easier it is to delete things, the easier it is to lose things.

The basic assumption made by the designers of OceanStore, however, was that none of the servers could be trusted. To support this, the system held only opaque/encrypted data. As such, the system could be used for more than files (e.g., for whole databases).

The system utilized nomadic data, meaning that data could be cached anywhere, unlike with NFS and AFS where only specific servers can cache the data.

==Why did the dream die?==

The biggest reason that caused the OceanStore dream to die was the assumption of mistrusting all the actors--everything else they did was right. This assumption, however, caused the system to become needlessly complicated as they had to rebuild ''everything'' to accommodate this assumption. This was also unrealistic as this is not an assumption that is generally made (i.e., it is normally assumed that at least some of the actors can be trusted). Other successful distributed systems are built on a more trusted model. In short, the solution that accommodates untrusted actors assumption is just too expensive.

=== Technology ===
As outlined above, the trust model (read: fundamentally untrusted model) is the most attractive feature which ultimately killed it. The untrusted assumption introduced a huge burden on the system, forcing technical limitations which made OceanStore uncompetitive in comparison to other solutions. It is just much more easy and convenient to trust a given system. It should be noted that every system is compromisable, despite this mistrust.

The public key system also reduces usability--if a user loses their key, they are completely out of luck and would need to acquire a new key. This also means that, if you wanted to remove their access over an object, you would have to re-encrypt the object with a new key and provide that key to said user, who would then have access to the object.

With regards to the security, there is no security mechanism on the server side. The server can not know who is accessing the data. On the economic side, the economic model is unconvincing with the way it is defined. The authors suggest that a collection of companies will host OceanStore servers and consumers will buy capacity (not unlike web-hosting today).

===Use Cases===
* Subset of the features already exist
** Blackberry and Google offer similar services.
** These current services owned by one company, not many providers.
** Can not sell back your services as a user.
*** ex. Can not sell your extra storage back to the utility.

==Pond: What insights?==

* They actually built it.
* Can't assume the use of any infrastructure, so they rebuild everything!
** Built over the internet.
** Tapestry (routing).
** GUID for object indentification. Object naming scheme.

==Benchmarks==
* Really good read speed, really bad write speed.

===Storage overhead===
* How much are they increasing the storage needed to implement their storage model.
* Factor of 4.8x the space needed (you'll have 1/5th the storage)
* Expensive, but good value (data is backed up, replicated, etc..)
* Considerations of importance before making an update
** burn more storage space as more updates are made

===Update performance===
* No data is mutated. It is diffed and archived.
* Creating a new version of an object and distributing that object.

===Benchmarks in a nutshell===
* Everything is expensive!
* High latency

==Other stuff==
* Byzantine fault tolerance
** byzantine fault tolerant network replicates the data in such a way that even if m nodes out of total n nodes,in a network,fail, you would still be able to recover the whole data. but as you increase the value of number m, the required network messages to be exchanges also increases, so there is a tradeoff.
** Assuming certain actors are malicious
* Bitcoin
** Trusted vs Untrusted.
** It is considered to be untrusted but it takes huge amount of trust when exchanges are made.

==What's worth salvaging from the dream?==
* Using spare resources in other locations.
* Similar routing system are used in large peer to peer systems.

==How to read a research paper==
* Start with Intro
** Figure out what the problem is
* then see the related work for context
* then go to conclusion. Focus on results.
* then fill in the gaps by reading specific parts of the body

DistOS 2014W Lecture 14

2014-03-09T15:25:24Z

Gbooth: /* Why did the dream die? */

=OceanStore=

==What is the dream?==
The dream was to create a persistent storage system that had high availability and was universally accessibly--a global, ubiquitous persistent data storage solution. OceanStore was meant to be utility managed by multiple parties, with no one party having total control/monopoly over the system. To support the goal of high availability, there was a high amount of redundancy and fault-tolerance. For high persistence, everything was archived--nothing was ever truly deleted. This can be likened to working in version control with "Commits". This is possibly due to the realization that the easier it is to delete things, the easier it is to lose things.

The basic assumption made by the designers of OceanStore, however, was that none of the servers could be trusted. To support this, the system held only opaque/encrypted data. As such, the system could be used for more than files (e.g., for whole databases).

The system utilized nomadic data, meaning that data could be cached anywhere, unlike with NFS and AFS where only specific servers can cache the data.

==Why did the dream die?==

The biggest reason that caused the OceanStore dream to die was the assumption of mistrusting all the actors--everything else they did was right. This assumption, however, caused the system to become needlessly complicated as they had to rebuild ''everything'' to accommodate this assumption. This was also unrealistic as this is not an assumption that is generally made (i.e., it is normally assumed that at least some of the actors can be trusted). Other successful distributed systems are built on a more trusted model. In short, the solution that accommodates untrusted actors assumption is just too expensive.

=== Technology ===
* The trust model is the most attractive feature which ultimately killed it.
** The untrusted assumption was a huge burden on the system. Forced technical limitations made them uncompetitive.
** It is just easier to trust a given system. More convenient.
** Every system is compromisable despite this mistrust
* Pub key system reduces usability
** If you loose your key, you're S.O.L.
** If you wanted to remove someone' access over an object, you would have to re-encrypt the object with a new key and provide the key to user who wtill have access to object
*security
**there is no security mechanism in servers side.
**can not now who access the data
*economic side
**The economic model is unconvincing as defined. The authors suggest that a collection of companies will host OceanStore servers, and consumers will buy capacity (not unlike web-hosting of today).

===Use Cases===
* Subset of the features already exist
** Blackberry and Google offer similar services.
** These current services owned by one company, not many providers.
** Can not sell back your services as a user.
*** ex. Can not sell your extra storage back to the utility.

==Pond: What insights?==

* They actually built it.
* Can't assume the use of any infrastructure, so they rebuild everything!
** Built over the internet.
** Tapestry (routing).
** GUID for object indentification. Object naming scheme.

==Benchmarks==
* Really good read speed, really bad write speed.

===Storage overhead===
* How much are they increasing the storage needed to implement their storage model.
* Factor of 4.8x the space needed (you'll have 1/5th the storage)
* Expensive, but good value (data is backed up, replicated, etc..)
* Considerations of importance before making an update
** burn more storage space as more updates are made

===Update performance===
* No data is mutated. It is diffed and archived.
* Creating a new version of an object and distributing that object.

===Benchmarks in a nutshell===
* Everything is expensive!
* High latency

==Other stuff==
* Byzantine fault tolerance
** byzantine fault tolerant network replicates the data in such a way that even if m nodes out of total n nodes,in a network,fail, you would still be able to recover the whole data. but as you increase the value of number m, the required network messages to be exchanges also increases, so there is a tradeoff.
** Assuming certain actors are malicious
* Bitcoin
** Trusted vs Untrusted.
** It is considered to be untrusted but it takes huge amount of trust when exchanges are made.

==What's worth salvaging from the dream?==
* Using spare resources in other locations.
* Similar routing system are used in large peer to peer systems.

==How to read a research paper==
* Start with Intro
** Figure out what the problem is
* then see the related work for context
* then go to conclusion. Focus on results.
* then fill in the gaps by reading specific parts of the body

DistOS 2014W Lecture 14

2014-03-09T15:22:16Z

Gbooth: /* What is the dream? */

=OceanStore=

==What is the dream?==
The dream was to create a persistent storage system that had high availability and was universally accessibly--a global, ubiquitous persistent data storage solution. OceanStore was meant to be utility managed by multiple parties, with no one party having total control/monopoly over the system. To support the goal of high availability, there was a high amount of redundancy and fault-tolerance. For high persistence, everything was archived--nothing was ever truly deleted. This can be likened to working in version control with "Commits". This is possibly due to the realization that the easier it is to delete things, the easier it is to lose things.

The basic assumption made by the designers of OceanStore, however, was that none of the servers could be trusted. To support this, the system held only opaque/encrypted data. As such, the system could be used for more than files (e.g., for whole databases).

The system utilized nomadic data, meaning that data could be cached anywhere, unlike with NFS and AFS where only specific servers can cache the data.

==Why did the dream die?==

* Biggest reason it died was it's assumption of mistrusting the actors.
** Everything else they did was right.
* Other successful distributed systems are built on a more trusted model.
* Complexity of the Ocean Store is too great.
** The solution is expensive.

=== Technology ===
* The trust model is the most attractive feature which ultimately killed it.
** The untrusted assumption was a huge burden on the system. Forced technical limitations made them uncompetitive.
** It is just easier to trust a given system. More convenient.
** Every system is compromisable despite this mistrust
* Pub key system reduces usability
** If you loose your key, you're S.O.L.
** If you wanted to remove someone' access over an object, you would have to re-encrypt the object with a new key and provide the key to user who wtill have access to object
*security
**there is no security mechanism in servers side.
**can not now who access the data
*economic side
**The economic model is unconvincing as defined. The authors suggest that a collection of companies will host OceanStore servers, and consumers will buy capacity (not unlike web-hosting of today).

===Use Cases===
* Subset of the features already exist
** Blackberry and Google offer similar services.
** These current services owned by one company, not many providers.
** Can not sell back your services as a user.
*** ex. Can not sell your extra storage back to the utility.

==Pond: What insights?==

* They actually built it.
* Can't assume the use of any infrastructure, so they rebuild everything!
** Built over the internet.
** Tapestry (routing).
** GUID for object indentification. Object naming scheme.

==Benchmarks==
* Really good read speed, really bad write speed.

===Storage overhead===
* How much are they increasing the storage needed to implement their storage model.
* Factor of 4.8x the space needed (you'll have 1/5th the storage)
* Expensive, but good value (data is backed up, replicated, etc..)
* Considerations of importance before making an update
** burn more storage space as more updates are made

===Update performance===
* No data is mutated. It is diffed and archived.
* Creating a new version of an object and distributing that object.

===Benchmarks in a nutshell===
* Everything is expensive!
* High latency

==Other stuff==
* Byzantine fault tolerance
** byzantine fault tolerant network replicates the data in such a way that even if m nodes out of total n nodes,in a network,fail, you would still be able to recover the whole data. but as you increase the value of number m, the required network messages to be exchanges also increases, so there is a tradeoff.
** Assuming certain actors are malicious
* Bitcoin
** Trusted vs Untrusted.
** It is considered to be untrusted but it takes huge amount of trust when exchanges are made.

==What's worth salvaging from the dream?==
* Using spare resources in other locations.
* Similar routing system are used in large peer to peer systems.

==How to read a research paper==
* Start with Intro
** Figure out what the problem is
* then see the related work for context
* then go to conclusion. Focus on results.
* then fill in the gaps by reading specific parts of the body

DistOS 2014W Lecture 12

2014-02-13T23:13:45Z

Gbooth:

==Introduction==

Chubby, developed at Google, was designed to be a coarse-grained locking service for use within loosely coupled distributed systems (i.e., a network consisting of a high number of small machines). The key contribution was the implementation of Chubby (i.e., there were no new algorithms designed/introduced).

==Design==

The funny thing is that Chubby is essentially a filesystem (with files, file permissions, reading/writing, a hierarchal structure, etc.) with a few caveats. Mainly that any file can act as a reader/writer lock and that only whole file operations are performed (i.e., the whole file is written or read), as the files are quite small (256K max).

All the locks are fully advisory, meaning others can "go around" whoever has the lock to access the resource (for reading and, sometimes, writing), as opposed to mandatory, mandatory locks giving completely exclusive access to a resource. It can be noted that Linux also utilizes advisory locks as opposed to Windows, which only utilizes mandatory locks. This could be noted as a shortcoming of Windows as, when anything changes regarding the system, the system must be completely rebooted as the mandatory locks on files end up being held too long. With advisory locks, as in Linux, the system need only be rebooted when the kernel is modified/updated.

Chubby also functions as a name server, but only really for functional names/roles , such as for the mail server or a GFS server (i.e., Chubby is mainly used as a name server for logical/symbolic names for roles). As a name server, Chubby provides guarantees not given with DNS (e.g., DNS is subject to a stale cache) as Chubby provides a unified view of the way things are in the system. The name-value mappings in Chubby allow for a consistent, real-time, overall view of the entire system.

Chubby was made coarse-grained for scalability as coarse-grained locks give the ability to create a distributed system while the fine-grained locks wouldn't scale well. It can also be noted that a fine-grained lock could be implemented on top of the coarse-grained locks. The entire point of Chubby was to give ultra-high availability and integrity.

==Implementation==

* paxos algorithm

==use cases==

==Discussion==

Where else do we see things such as Chubby? Where would you want this consistent, overall view?

You would want this consistent view in any sort of synchronized set of files across a set of systems, such as Dropbox. The main tenants of Chubby's design would hold where you would want to make sure there was an online consensus. It should be noted that this is not like version control as, with version control, everyone has their own copy which are all merged later. However, in this type of system, there is only one version available throughout the distributed system. Chubby's design would differ from Dropbox in that Dropbox is designed so that you can work offline and then synchronize your changes once you are online again (i.e., there can sometimes be more than one version of a file meaning you lack the consistent, overall view given by Chubby).

DistOS 2014W Lecture 4

2014-01-16T16:10:51Z

Gbooth: /* Graphics */

Discussions on the Alto

==CPU, Memory, Disk==

====CPU====

The general hardware architecture of the CPU was biased towards the user, meaning that a greater focus was put on IO capabilities and less focus was put on computational power (arithmetic etc). There were two levels of task-switching; the CPU provided sixteen fixed-priority tasks with hardware interrupts, each of which was permanently assigned to a piece of hardware. Only one of these tasks (the lowest-priority) was dedicated to the user. This task actually ran a virtualized BCPL machine (a C-like language); the user had no access at all to the underlying microcode. Other languages could be emulated as well.

====Memory====

The Alto started with 64K of 16-bit words of memory and eventually grew to 256K words. However, the higher memory was not accessible except through special tricks, similar to the way that memory above 4GB is not accessible today on 32-bit systems without special tricks.

====Task Switching====

One thing that was confusing was that they refer to tasks both as the 16 fixed hardware tasks and the many software tasks that could be multiplexed onto the lowest-priority of those hardware tasks. In either case, task switching was cooperative; until a task gave up control by running a specific instruction, no other task could run. From a modern perspective this looks like a major security problem, since malicious software could simply never relinquish the CPU. However, the fact that hardware was first-class in this sense (with full access to the CPU and memory) made the hardware simpler because much of the complexity could be done in software. Perhaps the first hints of what we now think of as drivers?

====Disk and Filesystem====

To make use of disk controller read,write,truncate,delete and etc. commands were made available.To reduce the risk of global damage structural information was saved to label in each page.hints mechanism was also a available using directory get where file resides in disk.file integrity a was check using seal bit and label.

==Ethernet, Networking protocols==

==Graphics, Mouse, Printing==

===Graphics===

A lot of time was spent on what paper and ink provides us in a display sense, constantly referencing an 8.5 by 11 piece of paper as the type of display they were striving for. This showed what they were attempting to emulate in the Alto's display. The authors proposed 500 - 1000 black or white bits per inch of display (i.e. 500 - 1000 dpi). However, they were unable to pursue this goal, instead settling for 70 dpi for the display, allowing them to show things such as 10 pt text. They state that a 30 Hz refresh rate was found to not be objectionable. Interestingly, however, we would find this objectionable today--most likely from being spoiled with the sheer speed of computers today, whereas the authors were used to slower performance. The Alto's display took up '''half''' the Alto's memory, a choice we found very interesting.

Another interesting point was that the authors state that they thought it was beneficial that they could access display memory directly rather than using conventional frame buffer organizations. While we are unsure of what they meant by traditional frame buffer organizations, it is interesting to note that frame buffer organizations is what we use today for our displays.

===Mouse===

The mouse outlined in the paper was 200 dpi (vs. a standard mouse from Apple which is 1300 dpi) and had three buttons (one of the standard configurations of mice that are produced today). They were already using different mouse cursors (i.e., the pointer image of the cursor on screen). The real interesting point here is that the design outlined in the paper was so similar to designs we still use today. The only real divergence was the use of optical mice, although the introduction of optical mice did not altogether halt the use of non-optical mice. Today, we just have more flexibility with regards to how we design mice (e.g., having a scroll wheel, more buttons, etc.).

===Printer===

They state that the printer should print, in one second, an 8.5 by 11 inch page defined with 350 dots/inch (roughly 4000 horizontal scan lines of 3000 dots each). Ironically enough, this is not even what they had wanted for the actual Alto display. However, they did not have enough memory to do this and had to work around this by using things such as an incremental algorithm and reducing the number of scan lines. We were disappointed that they did not actually discuss the hardware implementation of the printer, only the software controller. However, it is interesting that the fact they are dividing the memory requirements of the printer between the hardware itself and the computer was quite a modern idea at the time, and still is.

===Other Interesting Notes===

We found it interesting that peripheral devices were included at all.

The author makes a passing mention to having a tablet to draw on. However, he stated that no one really liked having the tablet as it got in the way of the keyboard.

The recurring theme of lack of memory to implement what they had originally envisioned.

==Applications, Programming Environment==

DistOS 2014W Lecture 4

2014-01-16T16:00:01Z

Gbooth: /* Printer */

Discussions on the Alto

==CPU, Memory, Disk==

====CPU====

The general hardware architecture of the CPU was biased towards the user, meaning that a greater focus was put on IO capabilities and less focus was put on computational power (arithmetic etc). There were two levels of task-switching; the CPU provided sixteen fixed-priority tasks with hardware interrupts, each of which was permanently assigned to a piece of hardware. Only one of these tasks (the lowest-priority) was dedicated to the user. This task actually ran a virtualized BCPL machine (a C-like language); the user had no access at all to the underlying microcode. Other languages could be emulated as well.

====Memory====

The Alto started with 64K of 16-bit words of memory and eventually grew to 256K words. However, the higher memory was not accessible except through special tricks, similar to the way that memory above 4GB is not accessible today on 32-bit systems without special tricks.

====Task Switching====

One thing that was confusing was that they refer to tasks both as the 16 fixed hardware tasks and the many software tasks that could be multiplexed onto the lowest-priority of those hardware tasks. In either case, task switching was cooperative; until a task gave up control by running a specific instruction, no other task could run. From a modern perspective this looks like a major security problem, since malicious software could simply never relinquish the CPU. However, the fact that hardware was first-class in this sense (with full access to the CPU and memory) made the hardware simpler because much of the complexity could be done in software. Perhaps the first hints of what we now think of as drivers?

====Disk and Filesystem====

==Ethernet, Networking protocols==

==Graphics, Mouse, Printing==

===Graphics===

A lot of time was spent on what paper and ink provides us in a display sense, constantly referencing an 8.5 by 11 piece of paper as the type of display they were striving for. This showed what they were attempting to emulate in the Alto's display. The authors proposed 500 - 1000 black or white bits per inch of display (i.e. 500 - 100 dpi). However, they were unable to pursue this goal, instead settling for 70 dpi for the display, allowing them to show things such as 10 pt text. They state that a 30 Hz refresh rate was found to not be objectionable. Interestingly, however, we would find this objectionable today--most likely from being spoiled with the sheer speed of computers today, whereas the authors were used to slower performance. The Alto's display took up '''half''' the Alto's memory, a choice we found very interesting.

Another interesting point was that the authors state that they thought it was beneficial that they could access display memory directly rather than using conventional frame buffer organizations. While we are unsure of what they meant by traditional frame buffer organizations, it is interesting to note that frame buffer organizations is what we use today for our displays.

===Mouse===

The mouse outlined in the paper was 200 dpi (vs. a standard mouse from Apple which is 1300 dpi) and had three buttons (one of the standard configurations of mice that are produced today). They were already using different mouse cursors (i.e., the pointer image of the cursor on screen). The real interesting point here is that the design outlined in the paper was so similar to designs we still use today. The only real divergence was the use of optical mice, although the introduction of optical mice did not altogether halt the use of non-optical mice. Today, we just have more flexibility with regards to how we design mice (e.g., having a scroll wheel, more buttons, etc.).

===Printer===

They state that the printer should print, in one second, an 8.5 by 11 inch page defined with 350 dots/inch (roughly 4000 horizontal scan lines of 3000 dots each). Ironically enough, this is not even what they had wanted for the actual Alto display. However, they did not have enough memory to do this and had to work around this by using things such as an incremental algorithm and reducing the number of scan lines. We were disappointed that they did not actually discuss the hardware implementation of the printer, only the software controller. However, it is interesting that the fact they are dividing the memory requirements of the printer between the hardware itself and the computer was quite a modern idea at the time, and still is.

===Other Interesting Notes===

We found it interesting that peripheral devices were included at all.

The author makes a passing mention to having a tablet to draw on. However, he stated that no one really liked having the tablet as it got in the way of the keyboard.

The recurring theme of lack of memory to implement what they had originally envisioned.

==Applications, Programming Environment==

DistOS 2014W Lecture 4

2014-01-16T15:58:37Z

Gbooth: /* Other Interesting Notes */

Discussions on the Alto

==CPU, Memory, Disk==

====CPU====

The general hardware architecture of the CPU was biased towards the user, meaning that a greater focus was put on IO capabilities and less focus was put on computational power (arithmetic etc). There were two levels of task-switching; the CPU provided sixteen fixed-priority tasks with hardware interrupts, each of which was permanently assigned to a piece of hardware. Only one of these tasks (the lowest-priority) was dedicated to the user. This task actually ran a virtualized BCPL machine (a C-like language); the user had no access at all to the underlying microcode. Other languages could be emulated as well.

====Memory====

The Alto started with 64K of 16-bit words of memory and eventually grew to 256K words. However, the higher memory was not accessible except through special tricks, similar to the way that memory above 4GB is not accessible today on 32-bit systems without special tricks.

====Task Switching====

One thing that was confusing was that they refer to tasks both as the 16 fixed hardware tasks and the many software tasks that could be multiplexed onto the lowest-priority of those hardware tasks. In either case, task switching was cooperative; until a task gave up control by running a specific instruction, no other task could run. From a modern perspective this looks like a major security problem, since malicious software could simply never relinquish the CPU. However, the fact that hardware was first-class in this sense (with full access to the CPU and memory) made the hardware simpler because much of the complexity could be done in software. Perhaps the first hints of what we now think of as drivers?

====Disk and Filesystem====

==Ethernet, Networking protocols==

==Graphics, Mouse, Printing==

===Graphics===

A lot of time was spent on what paper and ink provides us in a display sense, constantly referencing an 8.5 by 11 piece of paper as the type of display they were striving for. This showed what they were attempting to emulate in the Alto's display. The authors proposed 500 - 1000 black or white bits per inch of display (i.e. 500 - 100 dpi). However, they were unable to pursue this goal, instead settling for 70 dpi for the display, allowing them to show things such as 10 pt text. They state that a 30 Hz refresh rate was found to not be objectionable. Interestingly, however, we would find this objectionable today--most likely from being spoiled with the sheer speed of computers today, whereas the authors were used to slower performance. The Alto's display took up '''half''' the Alto's memory, a choice we found very interesting.

Another interesting point was that the authors state that they thought it was beneficial that they could access display memory directly rather than using conventional frame buffer organizations. While we are unsure of what they meant by traditional frame buffer organizations, it is interesting to note that frame buffer organizations is what we use today for our displays.

===Mouse===

The mouse outlined in the paper was 200 dpi (vs. a standard mouse from Apple which is 1300 dpi) and had three buttons (one of the standard configurations of mice that are produced today). They were already using different mouse cursors (i.e., the pointer image of the cursor on screen). The real interesting point here is that the design outlined in the paper was so similar to designs we still use today. The only real divergence was the use of optical mice, although the introduction of optical mice did not altogether halt the use of non-optical mice. Today, we just have more flexibility with regards to how we design mice (e.g., having a scroll wheel, more buttons, etc.).

===Printer===

They state that the printer should print, in one second, an 8.5 by 11 inch page defined with 350 dots/inch (roughly 4000 horizontal scan lines of 3000 dots each). Ironically enough, this is not even what they had wanted for the actual Alto display. However, they did not have enough memory to do this and had to work around this by using things such as an incremental algorithm and reducing the number of scan lines.

===Other Interesting Notes===

We found it interesting that peripheral devices were included at all.

The author makes a passing mention to having a tablet to draw on. However, he stated that no one really liked having the tablet as it got in the way of the keyboard.

The recurring theme of lack of memory to implement what they had originally envisioned.

==Applications, Programming Environment==

DistOS 2014W Lecture 4

2014-01-16T15:58:16Z

Gbooth: /* Printer */

Discussions on the Alto

==CPU, Memory, Disk==

====CPU====

The general hardware architecture of the CPU was biased towards the user, meaning that a greater focus was put on IO capabilities and less focus was put on computational power (arithmetic etc). There were two levels of task-switching; the CPU provided sixteen fixed-priority tasks with hardware interrupts, each of which was permanently assigned to a piece of hardware. Only one of these tasks (the lowest-priority) was dedicated to the user. This task actually ran a virtualized BCPL machine (a C-like language); the user had no access at all to the underlying microcode. Other languages could be emulated as well.

====Memory====

The Alto started with 64K of 16-bit words of memory and eventually grew to 256K words. However, the higher memory was not accessible except through special tricks, similar to the way that memory above 4GB is not accessible today on 32-bit systems without special tricks.

====Task Switching====

One thing that was confusing was that they refer to tasks both as the 16 fixed hardware tasks and the many software tasks that could be multiplexed onto the lowest-priority of those hardware tasks. In either case, task switching was cooperative; until a task gave up control by running a specific instruction, no other task could run. From a modern perspective this looks like a major security problem, since malicious software could simply never relinquish the CPU. However, the fact that hardware was first-class in this sense (with full access to the CPU and memory) made the hardware simpler because much of the complexity could be done in software. Perhaps the first hints of what we now think of as drivers?

====Disk and Filesystem====

==Ethernet, Networking protocols==

==Graphics, Mouse, Printing==

===Graphics===

A lot of time was spent on what paper and ink provides us in a display sense, constantly referencing an 8.5 by 11 piece of paper as the type of display they were striving for. This showed what they were attempting to emulate in the Alto's display. The authors proposed 500 - 1000 black or white bits per inch of display (i.e. 500 - 100 dpi). However, they were unable to pursue this goal, instead settling for 70 dpi for the display, allowing them to show things such as 10 pt text. They state that a 30 Hz refresh rate was found to not be objectionable. Interestingly, however, we would find this objectionable today--most likely from being spoiled with the sheer speed of computers today, whereas the authors were used to slower performance. The Alto's display took up '''half''' the Alto's memory, a choice we found very interesting.

Another interesting point was that the authors state that they thought it was beneficial that they could access display memory directly rather than using conventional frame buffer organizations. While we are unsure of what they meant by traditional frame buffer organizations, it is interesting to note that frame buffer organizations is what we use today for our displays.

===Mouse===

The mouse outlined in the paper was 200 dpi (vs. a standard mouse from Apple which is 1300 dpi) and had three buttons (one of the standard configurations of mice that are produced today). They were already using different mouse cursors (i.e., the pointer image of the cursor on screen). The real interesting point here is that the design outlined in the paper was so similar to designs we still use today. The only real divergence was the use of optical mice, although the introduction of optical mice did not altogether halt the use of non-optical mice. Today, we just have more flexibility with regards to how we design mice (e.g., having a scroll wheel, more buttons, etc.).

===Printer===

They state that the printer should print, in one second, an 8.5 by 11 inch page defined with 350 dots/inch (roughly 4000 horizontal scan lines of 3000 dots each). Ironically enough, this is not even what they had wanted for the actual Alto display. However, they did not have enough memory to do this and had to work around this by using things such as an incremental algorithm and reducing the number of scan lines.

===Other Interesting Notes===

We found it interesting that peripheral devices were included at all.

The author makes a passing mention to having a tablet to draw on. However, he stated that no one really liked having the tablet as it got in the way of the keyboard.

==Applications, Programming Environment==

DistOS 2014W Lecture 4

2014-01-16T15:54:39Z

Gbooth: /* Graphics, Mouse, Printing */

Discussions on the Alto

==CPU, Memory, Disk==

The general hardware architecture of the CPU was biased towards the user, meaning that a greater focus was put on IO capabilities and less focus was put on computational power (arithmetic etc). There were two levels of task-switching; the CPU provided sixteen fixed-priority tasks with hardware interrupts, each of which was permanently assigned to a piece of hardware. Only one of these tasks (the lowest-priority) was dedicated to the user. This task actually ran a virtualized BCPL machine (a C-like language); the user had no access at all to the underlying microcode. Other languages could be emulated as well.

The Alto started with 64K of 16-bit words of memory and eventually grew to 256K words. However, the higher memory was not accessible except through special tricks, similar to the way that memory above 4GB is not accessible today on 32-bit systems without special tricks.

==Ethernet, Networking protocols==

==Graphics, Mouse, Printing==

===Graphics===

A lot of time was spent on what paper and ink provides us in a display sense, constantly referencing an 8.5 by 11 piece of paper as the type of display they were striving for. This showed what they were attempting to emulate in the Alto's display. The authors proposed 500 - 1000 black or white bits per inch of display (i.e. 500 - 100 dpi). However, they were unable to pursue this goal, instead settling for 70 dpi for the display, allowing them to show things such as 10 pt text. They state that a 30 Hz refresh rate was found to not be objectionable. Interestingly, however, we would find this objectionable today--most likely from being spoiled with the sheer speed of computers today, whereas the authors were used to slower performance. The Alto's display took up '''half''' the Alto's memory, a choice we found very interesting.

Another interesting point was that the authors state that they thought it was beneficial that they could access display memory directly rather than using conventional frame buffer organizations. While we are unsure of what they meant by traditional frame buffer organizations, it is interesting to note that frame buffer organizations is what we use today for our displays.

===Mouse===

The mouse outlined in the paper was 200 dpi (vs. a standard mouse from Apple which is 1300 dpi) and had three buttons (one of the standard configurations of mice that are produced today). They were already using different mouse cursors (i.e., the pointer image of the cursor on screen). The real interesting point here is that the design outlined in the paper was so similar to designs we still use today. The only real divergence was the use of optical mice, although the introduction of optical mice did not altogether halt the use of non-optical mice. Today, we just have more flexibility with regards to how we design mice (e.g., having a scroll wheel, more buttons, etc.).

===Printer===

===Other Interesting Notes===

We found it interesting that peripheral devices were included at all.

The author makes a passing mention to having a tablet to draw on. However, he stated that no one really liked having the tablet as it got in the way of the keyboard.

==Applications, Programming Environment==

DistOS 2014W Lecture 4

2014-01-16T15:53:49Z

Gbooth: /* Graphics, Mouse, Printing */

Discussions on the Alto

==CPU, Memory, Disk==

The general hardware architecture of the CPU was biased towards the user, meaning that a greater focus was put on IO capabilities and less focus was put on computational power (arithmetic etc). There were two levels of task-switching; the CPU provided sixteen fixed-priority tasks with hardware interrupts, each of which was permanently assigned to a piece of hardware. Only one of these tasks (the lowest-priority) was dedicated to the user. This task actually ran a virtualized BCPL machine (a C-like language); the user had no access at all to the underlying microcode. Other languages could be emulated as well.

The Alto started with 64K of 16-bit words of memory and eventually grew to 256K words. However, the higher memory was not accessible except through special tricks, similar to the way that memory above 4GB is not accessible today on 32-bit systems without special tricks.

==Ethernet, Networking protocols==

==Graphics, Mouse, Printing==

===Graphics===

A lot of time was spent on what paper and ink provides us in a display sense, constantly referencing an 8.5 by 11 piece of paper as the type of display they were striving for. This showed what they were attempting to emulate in the Alto's display. The authors proposed 500 - 1000 black or white bits per inch of display (i.e. 500 - 100 dpi). However, they were unable to pursue this goal, instead settling for 70 dpi for the display, allowing them to show things such as 10 pt text. They state that a 30 Hz refresh rate was found to not be objectionable. Interestingly, however, we would find this objectionable today--most likely from being spoiled with the sheer speed of computers today, whereas the authors were used to slower performance. The Alto's display took up '''half''' the Alto's memory, a choice we found very interesting.

Another interesting point was that the authors state that they thought it was beneficial that they could access display memory directly rather than using conventional frame buffer organizations. While we are unsure of what they meant by traditional frame buffer organizations, it is interesting to note that frame buffer organizations is what we use today for our displays.

===Mouse===

The mouse outlined in the paper was 200 dpi (vs. a standard mouse from Apple which is 1300 dpi) and had three buttons (one of the standard configurations of mice that are produced today). They were already using different mouse cursors (i.e., the pointer image of the cursor on screen). The real interesting point here is that the design outlined in the paper was so similar to designs we still use today. The only real divergence was the use of optical mice, although the introduction of optical mice did not altogether halt the use of non-optical mice. Today, we just have more flexibility with regards to how we design mice (e.g., having a scroll wheel, more buttons, etc.).

===Other Interesting Notes===

We found it interesting that peripheral devices were included at all.

==Applications, Programming Environment==

DistOS 2014W Lecture 4

2014-01-16T15:46:15Z

Gbooth: /* Graphics, Mouse, Printing */

Discussions on the Alto

==CPU, Memory, Disk==

The general hardware architecture of the CPU was biased towards the user, meaning that a greater focus was put on IO capabilities and less focus was put on computational power (arithmetic etc). There were two levels of task-switching; the CPU provided sixteen fixed-priority tasks with hardware interrupts, each of which was permanently assigned to a piece of hardware. Only one of these tasks (the lowest-priority) was dedicated to the user. This task actually ran a virtualized BCPL machine (a C-like language); the user had no access at all to the underlying microcode. Other languages could be emulated as well.

The Alto started with 64K of 16-bit words of memory and eventually grew to 256K words. However, the higher memory was not accessible except through special tricks, similar to the way that memory above 4GB is not accessible today on 32-bit systems without special tricks.

==Ethernet, Networking protocols==

==Graphics, Mouse, Printing==

===Graphics===

A lot of time was spent on what paper and ink provides us in a display sense, constantly referencing an 8.5 by 11 piece of paper as the type of display they were striving for. This showed what they were attempting to emulate in the Alto's display. The authors proposed 500 - 1000 black or white bits per inch of display (i.e. 500 - 100 dpi). However, they were unable to pursue this goal, instead settling for 70 dpi for the display, allowing them to show things such as 10 pt text. They state that a 30 Hz refresh rate was found to not be objectionable. Interestingly, however, we would find this objectionable today--most likely from being spoiled with the sheer speed of computers today, whereas the authors were used to slower performance. The Alto's display took up '''half''' the Alto's memory, a choice we found very interesting.

Another interesting point was that the authors state that they thought it was beneficial that they could access display memory directly rather than using conventional frame buffer organizations. While we are unsure of what they meant by ``traditional frame buffer organizations'', it is interesting to note that frame buffer organizations is what we use today for our displays.

==Applications, Programming Environment==

DistOS 2014W Lecture 1

2014-01-14T19:49:16Z

Gbooth:

'''What is an OS?''' An OS allows you to run on (slightly) different hardware. Here are some ideas of what and OS could mean and some functionalities and responsibilities that OSes include::
* A hardware abstraction such that hardware resources can be accessed by software
* Provides consistent execution environment, which hardware doesn't provide (ie. code written to interface -- think portable code)
* Manages I/O (such as user I/O, machine I/O i.e. network I/O, sensors, videos, etc.)
* Resource management through multiplexing and policy use
** Multiplexing (sharing): one resource wanted by multiple users
* Communication infrastructure (example Inter Process Communication mechanisms) between the users (process, applications) of the Operating System.
* OS turns a computer you want to a computer you want to program
* Manages synchronization and concurrency issues

An OS can be defined by the role it plays in the programming of systems. It takes care of resource management and creates abstraction. An OS turns hardware into the computer/api/interface you WANT to program.

This is similar to how the browser is becoming the OS of the web. The browser is
the key abstraction needed to run web apps. It is the interface web developers target.
It doesn't matter what you consume a given website on (eg. a phone, tablet,
etc.), the browser abstracts the device's hardware and OS away.

'''So, what's a distributed OS?'''

Anil prefers to think of this 'logically' than functionally/physically. This is
because the old distributed operating system (DOS) model applies to today's systems
(ie. managing multiple cores, etc). The traditional definition is systems that
manage their resources over a Network.

A lot of these definitions are hard to peg down because simplicity always gets in
the way of truth. These concepts to do not fit into well defined classes.

'''Anil's definition''' (following up on the similar note on what a traditional OS is, as seen above): "taking the distributed pieces of a system you have and
turning it into the system you WANT."

It is good to think about about DOS's within the context of who/what is in
control, in terms of who makes and enforces decisions in DOS. In essence, who is in charge? The traditional kernel-process model is a dictatorship. Authoritarian
model of control. The kernel controls what lives or dies. The internet, by
contrast, is decentralised (eg. DNS). Distributed systems may have distributed
policies where there is not one source of power. Even in DOS paradigm we can see instances of authoritarian/centralized approaches one example being the walled garden model employed by Apple iOS. Anil's observation is that centralized systems has an inherent fragility built into and these kind of systems come into existence and disappear after a while. Examples being AOL, Myspace. Even the Facebook also looks to be a possible candidate for a similar fate. Also, concentrations on policy will tend to fall apart in the future.

COMP 3000 2011 Report: Privatix

2011-12-19T22:54:17Z

Gbooth: /* Initialization */

=Part 1=

==Background==

The name of our chosen distribution is the Privatix Live-System. The target audience for this system are people that are concerned about privacy, anonymity and security when web-surfing, transporting/editing sensitive data, sending email etc. Therefore, the goals of this distribution are mainly security and privacy related which means being able to provide security-conscious tools and applications integrated into a portable Operating System (OS) for anyone to use at any time. The distribution is meant to be portable, coming in the form of a live Compact Diak (CD) which can be installed on an external device or a Universal Serial Bus (USB) flash drive with an encrypted password to ensure that all your data remains private, even if your external device is lost or compromised. It should be noted that the live CD is only meant for installing the OS onto a USB in order to provide a portable, privacy conscious OS. The user should not solely rely on the live CD as the OS does not yet implement password protection. This is due to the fact that there are no user accounts on the live CD, user accounts are only implemented once the full OS is installed on a USB. The Privatix Live-System incorporates many security-conscious tools for safe editing, carrying sensitive data, encrypted communication and anonymous web surfing such as built in software to encrypt external devices, IceWeasel and TOR. <ref name="privatix home">[http://www.mandalka.name/privatix/index.html.en Privatix home page](Last accessed 10-10-11)</ref>

This Privatix Live-System was developed in Germany by Markus Mandalka. It may be obtained by going to Markus Mandalka's website and navigating to the download page ([http://www.mandalka.name/privatix/download.html.en Mandalka]), selecting the version you wish to download (we chose the English version) and downloading it. The approximate size of the Privatix Live-System is 838 Megabytes (MB) for the full English version (there are smaller versions available which have had features such as GNOME removed).<ref name="Privatix download page">[http://www.mandalka.name/privatix/download.html.en Privatix download page](Last accessed 10-10-11)</ref>. The Privatix Live-System was based off of Debian ([http://distrowatch.com/table.php?distribution=debian Debian]).

==Installation/Startup==
[[File:PrivatixBoot.png|thumb|right|Privatix boot screen]]
[[File:PrivatixDesktop.png|thumb|right|Privatix desktop]]
Currently we have Privatix installed on an 8 Gigabyte (GB) USB stick in order to utilize the full power of the OS. However, Privatix can be used in a few ways other than installing it on an external device such as on a live CD/Digital Video Disk (DVD), or in a virtualized environment such as VirtualBox. It should be noted, however, that the full potential of the OS is only unlocked once the OS has been installed on an external device as it was meant to be. One main flaw in using either a virtual environment or the live CD is that user accounts, and hence password protection, are not implemented until the OS has been installed on an external device.

To install the Privatix-Live System, the user must first download the .iso from the download page ([http://www.mandalka.name/privatix/download.html.en Mandalka]). Once the .iso file is downloaded, it is possible to either burn the operating system to a CD/DVD, use VirtualBox, or install it to a USB stick.

===CD/DVD===
To install and boot Privatix with a CD/DVD, simply burn the operating system to a disk and boot from the CD/DVD created when prompted to in the BIOS. While using the Live CD, the user will have access to almost all features of the operating system. However, because no profiles were setup, if the user locks the computer, there will be no way to unlock it as no password was not setup. Note that the main purpose of the live CD/DVD is to install the OS on an external device.

===VirtualBox===
Using VirtualBox requires simply having VirtualBox installed, and when prompted for the installation media to select the .iso file downloaded for Privatix.

When the system starts up select the Live option. This brings up the main Desktop, while using VirtualBox the user will have access to all features available when using Privatix with the Live CD. However there is one small extra level of security, this is provided by the host operating system. this extra layer of security takes the form of the profile system of the host operating system.

===USB===
To install Privatix onto a USB stick, you first must be booted into Privatix Live through a CD/DVD. Then you need to click the install icon on the Desktop to begin installing to a device. It is then possible to select a device for Privatix to install itself on. The installer will ask you if you would like to fill your device with blank data, this makes accessing data/recovering what was originally on the device much harder. The installer will prompt you for a user password, as well as an admin password. The installer will then start it's time consuming process of installing Privatix to the device.

To boot into Privatix from the device, you can stop the computer booting, and then boot into the external device. During booting, Privatix will prompt you for your the password set up during the installation.

==Basic Operation==

===On An External Device===

The main way of utilizing the Privatix Live-System is done by installing the system on an external device. In our case, we used an 8 GB USB stick. When the system is installed on an external device, it is easy to use the system for its intended purpose--having portable anonymous and secure system. We tested this portable version of the system on several laptops with no trouble and no noticeable discretion in use between the different machines. We attempted to use the the system for the following use cases: anonymous web browsing, secure email, data encryption and secure data transportation.

Apart from this, Privatix also came with OpenOffice applications for editing all types of data and much of the basic GNOME functionality, including (but not limited to):
* Pidgin IM and Empathy IM Client for instant messaging
* Evolution Mail for sending and retrieving email
* gedit for text editing

====Anonymous Web Browsing====
[[File:TOR.png|thumb|right|TOR is enabled by default in Privatix]]
The main thing we liked about this system was the secure and anonymous web browsing. The default browser in the system is IceWeasal (an older version of GNU IceCat--a re-branding of FireFox compatible with both Linux and Mac systems) which comes equipped with security features not available by default in FireFox. The main add on that I liked was that The Onion Router (TOR) is installed and enabled by default (it can be disabled if the user wishes). TOR is an open source project meant to provide absolute anonymity online--mainly preventing anyone from learning your location or browsing habits--by routing webpage requests through virtual tunnels made up of individual TOR nodes. Since no two "paths" for a request are ever the same there is no way for your traffic to be monitored. <ref name="TOR Project - About">[https://www.torproject.org/about/overview.html.en TOR Project - About](Last accessed 10-10-11)</ref>

====Secure Email====

The Privatix Live-System also came equipped with the security-conscious email client IceDove--an unbranded ThunderBird mail client (a cross-platform email client that provides government-grade security features). The email client was easily setup and used, supporting digital signing and message encryption via certificates by default (as with TOR, this could be disabled if the user wished). <ref name="icedove">[http://packages.debian.org/sid/icedove IceDove](Last accessed 10-10-11)</ref>

====Data Encryption====
[[File:Encrypt.jpg|thumb|right|Software to encrypt external device]]
The Privatix Live-System also has the ability to encrypt external devices (besides the external device that the system is installed on). This meant that we could have an unlimited amount of encrypted data, not being limited to the size of the external device that the system itself is installed on. The ability to encrypt secondary external devices is very handy as much of the space on the external device that Privatix is installed on is taken up by the system itself, especially if one fills the device with blank decoy data on installation. The encryption software was easily used, well designed and was able to be utilized by absolute beginners of the system.

====Secure Data Transportation====
There are two ways that Privatix fulfills its secure data transportation goal:
# When saving data on the external device with the Privatix Live-System, the data is automatically encrypted and is also password protected (since the portable version of Privatix requires a password to use it). <ref name="Privatix FAQ">[http://www.mandalka.name/privatix/index.html.en Privatix FAQ](Last accessed 10-10-11)</ref>
# As mentioned above, Privatix allows for the encryption of secondary external devices, hence meaning that data can be securely transported without even having the Privatix Live-System with you.

====General Use====

Even with the additional security features not available in other distributions, Privatix would still be a very desirable live system to use. It is portable, especially once installed on an external device, and easily used with little bloatware. The default applications such as OpenOffice for data editing, Pidgin for instant messaging, various graphics editors, video player, and CD burner/extractor ensured that they system was still perfectly functional for everyday use, even with security, not intense functionality, being the main focus.

===Live CD and Virtual Box===

We found that running Privatix using the live CD and VirtualBox was equivalent.

When booting the live CD in VirtualBox, there are certain key features of the Privatix Live-System you are missing (mainly because these features are meant for the portable version to be installed on an external device). However, just booting from the live CD still gives a lot of the functionality I would use the system for--mainly the anonymous web browsing, secure email and data encryption. The key differences were the lack of portability and the inability to save any data on the live CD or VirtualBox environment.

When using only the live CD or VirtualBox all files are deleted when the system is shut down. In addition to, any files saved to the desktop by the user will not appear. They will be hidden from view, but can be viewed by opening the terminal and navigating to the desktop and running the ls command.

The main flaw in only using the system in these mediums is that the added protection of having a user account and password to access the system are no present on the live CD or when using Privatix in a virtual machine. This is due to the fact that Privatix does not implement user accounts and password protection until it has been fully installed onto an external device. As the main goal of this distribution is privacy, it would be highly recommended that the user fully install the OS onto an external device for the added security of password protection.

==Usage Evaluation==

During our use of Privatix, we found it preformed on par for what it was described as, a secure and portable system. The tools provided to encrypt data and the secure browser with add-ons for anonymity especially supported this belief. However we also found some parts of the distribution that were a cause for concern. To begin with, there was a slight language barrier as the system was originally written in German. This was made apparent by the frequent grammar mistakes in both the existing English documentation and the operating system itself indicating that English was not the primary language for the writers of this operating system. Most of the documentation for the operating system is also in German. Those who maintain Privatix and its project website are in the process of translating all their documentation as to be available in both English and German, though currently most of the supporting documentation and FAQ are in German. This made it hard to troubleshoot anything that went wrong with the system during installation or use.

We also noticed that there was no wireless drivers on either portable versions of the OS (installed on an external device or simply using the Live CD or booting up in a virtual machine) so wireless networks could not be connected to. This causes a problem because an operating system on a USB stick should be completely portable, however this driver requires you to have a hard line to use the Internet. It was also noticed that when using Privatix in VirtualBox that even though there was no wireless drivers in Privatix, the wireless capability was provided by the host OS (Windows).

Lastly, when we tried to install Privatix onto a USB it took several attempts. We discovered that to avoid many of the problems we encountered, it is better to use a larger (preferably at least 8GBs) external device for installation and to defer from filling the external device with blank decoy data during installation on an external device.

However once connected to the Internet, all software seems to work as it should. The more basic applications such as OpenOffice, the instant messaging and email clients, multimedia applications etc. function with no problems encountered, working much as they do in any other Linux distribution. The security tools also seem to work as they should. However since we do not know how to test the limits of its security measures we do not know for sure how secure these programs actually are. Overall, Privatix seems to be a very functional and portable distribution, allowing users access to standard applications for tasks such as editing and transporting data, sending/receiving email, instant messaging and multimedia applications with the added bonus of being completely secure and anonymous.

=Part 2=
==Software Packaging==
[[File:dpkg_out.png|thumb|right|Package listing, dpkg]]
[[File:aptitude_out.png|thumb|right|Package listing, aptitude]]
The packaging format that was used for the Privatix-Live System was DEB (based on the Debian packaging format). <ref name="privatix distrowatch">[http://distrowatch.com/table.php?distribution=privatix Privatix Distrowatch Page](Last accessed 12-18-11)</ref> The utilities used with this packaging format were dpkg and aptitude. Dpkg is used as the operating system's package management utility, with aptitude acting as the more user-friendly front end version. Aptitude made finding a list of installed packages quite easy. Aptitude allows you to see a full list of installed packages, with the packages being segregated into categories such as mail, web, shells and utils. As well as using aptitude, the command line can be used to access a list of installed packages. To do this, input the following in terminal and a list of all installed packages is generated. <ref name="dpkg man page">[http://manpages.ubuntu.com/manpages/lucid/man1/dpkg.1.html Dpkg Man Page](Last accessed 12-11-11)</ref>

$ dpkg -l

Though knowing how to do this in command line is useful, we found that using aptitude was generally better as the packages are segregated into categories which made viewing the list of installed packages more simple.

To add a package within Privatix, we found the easiest way was to use the one of the following commands provided by dpkg:

$ dpkg -i <package name>
or
$ dpkg --install <package name>

These commands function in the same way which means they will either install a package, or upgrade already installed versions of the package. <ref name="dpkg man page">[http://manpages.ubuntu.com/manpages/lucid/man1/dpkg.1.html Dpkg Man Page](Last accessed 12-11-11)</ref>

To remove a package within Privatix, we found the easist way was to use either of the following commands provided by dpkg:

$ dpkg -r <package name>
or
$ dpkg -P <package name>

When using "dpkg -r <package name>", everything related to the package ''except'' the configuration files are removed. To fully remove a package, however, we used "dpkg -P <package name>" which removes the entire package, including the configuration files. <ref name="dpkg man page">[http://manpages.ubuntu.com/manpages/lucid/man1/dpkg.1.html Dpkg Man Page](Last accessed 12-11-11)</ref>

We found that the software catalog for this distribution was quite extensive, especially since this distribution is meant to be portable. Privatix includes all the standard packages included with Debian (e.g. libc), as well as several other utilities meant to increase security and privacy while using the system such as IceDove, TOR and TORButton.

==Major Package Versions==

For this section of the report, we needed to speculate as to why a certain ''version'' of a package was included, not just the package itself. We determined, with the release date of Privatix <ref name="privatix distrowatch">[http://distrowatch.com/table.php?distribution=privatix Privatix on Distrowatch](Last accessed 12-19-11)</ref>, that the usual reasoning behind a certain version of a package being included was that the included version was the stable release of the package at that time. We also needed to determine how heavily modified by the distribution's author packages included within our distribution were. However, the distribution's author has stated that everything included is mainly based on Debian. <ref name="privatix documentation">[http://www.mandalka.name/privatix/doc.html Privatix Documentation (German)](Last accessed 12-11-11)</ref> The packages within Privatix have not been modified, the distribution's author has mainly brought together several security and privacy conscious utilities into one distribution for portable and daily use. As such, many of the packages that come with the standard install of Privatix have been included since they are included with the standard install of Debian at the time this distribution was made. Please also note that this reference was taken from the main page of the distribution but that, to view it, you will need to translate it (we used Google translate) as much of the documentation for this distribution is in German.

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th width="10%">
<p align="left">Category</p>
</th>
<th width="15%">
<p align="left">Package</p>
</th>
<th width="10%">
<p align="left">Version</p>
</th>
<th width="15%">
<p align="left">Upstream Source</p>
</th>
<th width="20%">
<p align="left">Vintage</p>
</th>
<th width="30%">
<p align="left">Package Details</p>
</th>
</tr>
<tr>
<td rowspan="3">Kernel</td>
<td>linux-base</td>
<td>2.6.32-31 </td>
<td rowspan="3">None Provided</td>
<td rowspan="3">
This version of the kernel was released in December of 2009, making it just under two years old. <ref name="linux kernel">[http://kernelnewbies.org/Linux_2_6_32 Linux Kernel v2.6.32 Info Page](Last accessed 12-11-11)</ref> The newest stable version of the Linux kernel was released just yesterday (11/11/2011), this version being listed as 3.1.1. <ref name="current kernel">[http://www.kernel.org/ Current Stable Linux Kernel](Last accessed 12-11-11)</ref> This puts the version of the Linux kernel on Privatix as being two years behind the current stable version of the Linux kernel.</td>
<td rowspan="3">
We believe that these packages were included within the distribution as they are the standard packages for the Linux kernel included in the standard install of Debian at the time Privatix was released.</td>
</tr>
<tr>
<td>linux-image-2.6.32-5-686</td>
<td>2.6.32-31</td>
</tr>
<tr>
<td>linux-image-2.6-282</td>
<td>2.6.32+39</td>
</tr>

<tr>
<td rowspan="2">libc</td>
<td>libc-bin</td>
<td rowspan="2">2.11.2-10</td>
<td rowspan="2">http://www.eglibc.org</td>
<td rowspan="2">
This version of libc was released in January 2011, making it approximately 11 months old.<ref name="eglibc">[http://packages.qa.debian.org/e/eglibc.html eglibc Source Package on Debian](Last accessed 12-11-11)</ref> This version is also the current stable version of libc, as listed on Debian. <ref name="eglibc">[http://packages.qa.debian.org/e/eglibc.html eglibc Source Package on Debian](Last accessed 12-11-11)</ref> However, a newer, unstable version (version 2.13-21), is currently undergoing testing.</td>
<td rowspan="2">This package was included as it is also included in the standard install of Debian as well as that all Linux-based systems come with a version of libc.</td>
</tr>
<tr>
<td>libc6</td>
</tr>

<tr>
<td rowspan="1">Shell</td>
<td>bash</td>
<td rowspan="1">4.1-3</td>
<td rowspan="1">http://tiswww.case.edu/php/chet/bash/bashtop.html</td>
<td rowspan="1">This version of bash was released in, approximately, April 2010. <ref name="bash">[http://packages.qa.debian.org/b/bash.html bash Source Package on Debian](Last accessed 12-11-11)</ref> It is also the current stable version of bash. <ref name="bash">[http://packages.qa.debian.org/b/bash.html bash Source Package on Debian](Last accessed 12-11-11)</ref> However, last month, version 4.2 of bash was pushed into testing and became the current experimental version.<ref name="bash">[http://packages.qa.debian.org/b/bash.html bash Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">This package was included as bash is the version of command line included with the standard install of Debian.</td>
</tr>

<tr>
<td rowspan="1">Utilities</td>
<td>busybox</td>
<td rowspan="1">1:1.17.1-8</td>
<td rowspan="1">http://www.qtsoftware.com/</td>
<td rowspan="1">This version of busybox was released in, approximately, November 2010. <ref name="busybox">[http://packages.qa.debian.org/b/busybox.html busybox Source Package on Debian](Last accessed 12-11-11)</ref> It is also the current stable version of busybox as listed on Debian. <ref name="busybox">[http://packages.qa.debian.org/b/busybox.html busybox Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">This package was included as it the version of busybox included with the standard install of Debian.</td>
</tr>
<tr>

<tr>
<td rowspan="1">Software Packaging</td>
<td>dpkg</td>
<td rowspan="1">1.15.8.10</td>
<td rowspan="1">http://wiki.debian.org/Teams/Dpkg</td>
<td rowspan="1">
This version of dpkg was released in February of 2011, making it 10 months old. <ref name="dpkg changelog">[https://launchpad.net/ubuntu/+source/dpkg/1.15.8.10ubuntu1 Dpkg Changelog](Last accessed 12-11-11)</ref> The current stable version of dpkg, as listed on Debian, is version 1.15.8.11 which was released in April of 2011. <ref name="dpkg">[http://packages.qa.debian.org/d/dpkg.html Dpkg Source Package on Debian](Last accessed 12-11-11)</ref> This would put the version of dpkg included with Privatix at 3 months behind the latest stable version.</td>
<td rowspan="1">This package was included since dpkg is the package management system of Debian, the distribution that Privatix is based off of.</td>
</tr>

<tr>
<td rowspan="3">Web Browser</td>
<td>IceWeasel</td>
<td rowspan="1">3.5.16-6</td>
<td rowspan="1">None Provided</td>
<td rowspan="1">
This version of IceWeasel was released in March 2011, making it 9 months old. <ref name="iceweasel">[http://packages.qa.debian.org/i/iceweasel.html IceWeasel Source Package on Debian](Last accessed 12-11-11)</ref> The newest stable version is version 3.5.16-11 which was released in November 2011. <ref name="iceweasel">[http://packages.qa.debian.org/i/iceweasel.html IceWeasel Source Package on Debian](Last accessed 12-11-11)</ref> This would put the version of IceWeasel included with Privatix at 9 months behind the latest stable release.</td>
<td rowspan="1">
IceWeasel was included within this distribution as it is a more security conscious browser than more mainstream browsers such as Mozilla Firefox. IceWeasel, an older version of GNU IceCat (a rebranding of FireFox), comes equipped with security features not available by default in FireFox.</td>
</tr>
<tr>
<td>Tor</td>
<td>0.201029-1</td>
<td>https://www.torproject.org</td>
<td>
This version of TOR was released in January 2011, making it 11 months old. <ref name="tor changelog">[https://launchpad.net/ubuntu/+source/tor/0.2.1.29-1 TOR Changelog](Last accessed 12-11-11)</ref> The latest stable release of TOR is version 0.2.1.30-1 which was released in July 2011. <ref name="tor">[https://launchpad.net/ubuntu/+source/tor TOR on LaunchPad](Last accessed 12-11-11)</ref></td>
<td>
This package was included to help increase security, anonymity and privacy while web browsing which is one of the main goals of the Privatix distribution. For more information on TOR, see the Basic Operation section of the report, under Anonymous Web Browsing. </td>
</tr>
<tr>
<td>TOR Button (xul-ext-torbutton)</td>
<td>1.2.5-3</td>
<td>https://www.torproject.org/torbutton/</td>
<td>
This version of TOR Button was released in October 2010, making it just over a year old.<ref name="torbutton">[https://www.torproject.org/torbutton/ TORButton](Last accessed 12-11-11)</ref> The newest stable version of this program is version 1.4.4.1 which was released last month. <ref name="torbutton">[https://www.torproject.org/torbutton/ TORButton](Last accessed 12-11-11)</ref> This would put the version of TORButton included with Privatix at about a year behind the latest stable release.</td>
<td>
This package was included in order to add to the functionality of TOR. This add-on allows the user to enable and disable TOR with the push of a button, located in the corner of their browser. </td>
</tr>

<tr>
<td rowspan="1">Email</td>
<td>icedove</td>
<td rowspan="1">3.0.11-1+s</td>
<td rowspan="1">None Provided</td>
<td rowspan="1">
This version of IceDove is the current stable version as listed on Debian. <ref name="icedove debian">[http://packages.qadebian.org/i/icedove.html IceDove Source Package on Debian](Last accessed 12-11-11)</ref> However, this version was included within Privatix before it was made stable. It was released as an unstable version in December 2010 and was later released as the current stable version in October 2011. <ref name="icedove debian">[http://packages.qadebian.org/i/icedove.html IceDove Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">
This email client was included due to the fact that it is a more security-conscious email client, providing government-grade security features, than others such as the regular version of ThunderBird. For more information on this program, refer to the Basic Operation section of this report under Secure Email.</td>
</tr>

<tr>
<td rowspan="1">Other</td>
<td>pidgin</td>
<td rowspan="1">2.7.3.1+sq</td>
<td rowspan="1">http://www.pidgin.im</td>
<td rowspan="1">
This version of the Pidgin was released in October 2010, and is also the current stable version of Pidgin as listed on Debian. <ref name="pidgin">[http://packages.qa.debian.org/p/pidgin.html Pidgin Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">
This package was included as Pidgin is the default IM client included with the standard install of Debian, the system on which Privatix is based.</td>
</tr>
</table>

==Initialization==

Privatix generally follows the same initialization process as Debian. Privatix initializes by first executing first the BIOS then the boot loader code. <ref name="debian boot process">[http://wiki.debian.org/BootProcess#System_Initialization Debian Boot Process](Last accessed 12-11-11)</ref> Privatix uses the same boot loader as Debian which is System V initialization. /etc/inittab is the configuration file, with the /sbin/init program initializing the system following the description in this configuration file. <ref name="debian boot process">[http://wiki.debian.org/BootProcess#System_Initialization Debian Boot Process](Last accessed 12-11-11)</ref> inittab will set the default run level of Privatix, which is run level 2. Following this, all the scripts located in /etc/rc2.d are executed alphabetically. <ref name="debian boot process">[http://wiki.debian.org/BootProcess#System_Initialization Debian Boot Process](Last accessed 12-11-11)</ref> These scripts are:

[[File:pstree1.png|thumb|right|Process tree after start up]]
[[File:pstree_.png|thumb|right|Process tree after start up cont.]]

* '''S01polipo''': polipo web cache--a small and fast caching web proxy
* '''S01rsyslog''': enhanced multi-thread syslogd which is Linux system logging utility
* '''S01sudo''': provides sudo
* '''S02cron''': starts the scheduler of the system
* '''S02dbus''': utility to send messages between processes and applications
* '''S02rsync''': opens rsync--a program that allows files to be copied to and from remote machines
* '''S02tor''': starts TOR (for more information, see above)
* '''S03avahi-daemon''': starts the zeroconf daemon which is used for configuring the network automatically
* '''S03bluetooth''': launches bluetooth
* '''S03networ-manager''': starts a daemon that automatically switches network connections to the best available connection
* '''S04openvpn''': starts openvpn service--a generic vpn service
* '''S05gdm3''': script for the GNOME display manager
* '''S06bootlogs''': the log file handling to be done during bootup--mainly things that don't need to be done particularly early in the boot process
* '''S07rc.local''': runs the /etc/rc.local file if it exists--by default this script does nothing, it is used only to exit
* '''S07rmologin''': removes the /etc/nologin file as the last step in the boot process
* '''S07stop-bootlogd''': runs the /etc/rc.local file again, if it exists--by default this script does nothing, it is used only to exit

Following this, the system is initialized. The processes running on the newly initialized system and what initializes them are as follows:

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr>
<th width="20%"> <b>Process Name</b> </th>
<th width="60%"> <b>Description</b> </th>
<th width="20%"> <b>Initialized By</b> </th>
</tr>
<tr>
<td> NetworkManager </td>
<td> Daemon that automatically switches network connections to the best available connection </td>
<td> S03networ-manager init script </td>
</tr>

<tr>
<td> avahi-daemon </td>
<td> zeroconf daemon which is used for configuring the network automatically </td>
<td> S03avahi-daemon init script </td>
</tr>

<tr>
<td> bluetoothd </td>
<td> Enables bluetooth to be used </td>
<td> S03bluetooth init script </td>
</tr>

<tr>
<td> cron </td>
<td> Scheduler of Debian systems </td>
<td> S02cron init script </td>
</tr>

<tr>
<td> dbus-launch </td>
<td> Utility to send messages between processes and applications </td>
<td> S02dbus init script </td>
</tr>

<tr>
<td> gdm3 </td>
<td rowspan="4"> GNOME display manager </td>
<td rowspan="4"> S05gdm3 init script </td>
</tr>

<tr>
<td> gnome-screensav </td>
</tr>

<tr>
<td> gnome-settings- </td>
</tr>

<tr>
<td> gnome-terminal </td>
</tr>

<tr>
<td> polipo </td>
<td> polipo web cache--a small and fast caching web proxy </td>
<td> S01polipo init script </td>
</tr>

<tr>
<td> tor </td>
<td> TOR is an open source project meant to provide anonymity online--mainly preventing anyone from learning your location or browsing habits--by routing webpage requests through virtual tunnels made up of individual TOR nodes. Since no two "paths" for a request are ever the same there is no way for your traffic to be monitored. </td>
<td> S02tor init script </td>
</tr>

</table>

We found this information by first confirming that Privatix used the same style of initializing as Debian. Once we ascertained this, we researched the Debian boot process. Privatix followed the same steps up until the loading of the scripts, which had some scripts that differed from Debian (e.g. TOR). Following this, we researched each of the scripts run on Privatix's default boot level of 2. The scripts are listed above, in the order they execute. To find the purpose of each of the scripts and what programs they opened, we manually went through each of the scripts. To find the processes running on the newly initialized system, we used the command "ps tree". Once we had a list of the running processes, we researched the purpose of each process. To find how each process was initialized, we manually searched through the initialization scripts and matched each process with their initialization script.

=References=

<references />

COMP 3000 2011 Report: Privatix

2011-12-19T22:43:42Z

Gbooth: /* Software Packaging */

=Part 1=

==Background==

The name of our chosen distribution is the Privatix Live-System. The target audience for this system are people that are concerned about privacy, anonymity and security when web-surfing, transporting/editing sensitive data, sending email etc. Therefore, the goals of this distribution are mainly security and privacy related which means being able to provide security-conscious tools and applications integrated into a portable Operating System (OS) for anyone to use at any time. The distribution is meant to be portable, coming in the form of a live Compact Diak (CD) which can be installed on an external device or a Universal Serial Bus (USB) flash drive with an encrypted password to ensure that all your data remains private, even if your external device is lost or compromised. It should be noted that the live CD is only meant for installing the OS onto a USB in order to provide a portable, privacy conscious OS. The user should not solely rely on the live CD as the OS does not yet implement password protection. This is due to the fact that there are no user accounts on the live CD, user accounts are only implemented once the full OS is installed on a USB. The Privatix Live-System incorporates many security-conscious tools for safe editing, carrying sensitive data, encrypted communication and anonymous web surfing such as built in software to encrypt external devices, IceWeasel and TOR. <ref name="privatix home">[http://www.mandalka.name/privatix/index.html.en Privatix home page](Last accessed 10-10-11)</ref>

This Privatix Live-System was developed in Germany by Markus Mandalka. It may be obtained by going to Markus Mandalka's website and navigating to the download page ([http://www.mandalka.name/privatix/download.html.en Mandalka]), selecting the version you wish to download (we chose the English version) and downloading it. The approximate size of the Privatix Live-System is 838 Megabytes (MB) for the full English version (there are smaller versions available which have had features such as GNOME removed).<ref name="Privatix download page">[http://www.mandalka.name/privatix/download.html.en Privatix download page](Last accessed 10-10-11)</ref>. The Privatix Live-System was based off of Debian ([http://distrowatch.com/table.php?distribution=debian Debian]).

==Installation/Startup==
[[File:PrivatixBoot.png|thumb|right|Privatix boot screen]]
[[File:PrivatixDesktop.png|thumb|right|Privatix desktop]]
Currently we have Privatix installed on an 8 Gigabyte (GB) USB stick in order to utilize the full power of the OS. However, Privatix can be used in a few ways other than installing it on an external device such as on a live CD/Digital Video Disk (DVD), or in a virtualized environment such as VirtualBox. It should be noted, however, that the full potential of the OS is only unlocked once the OS has been installed on an external device as it was meant to be. One main flaw in using either a virtual environment or the live CD is that user accounts, and hence password protection, are not implemented until the OS has been installed on an external device.

To install the Privatix-Live System, the user must first download the .iso from the download page ([http://www.mandalka.name/privatix/download.html.en Mandalka]). Once the .iso file is downloaded, it is possible to either burn the operating system to a CD/DVD, use VirtualBox, or install it to a USB stick.

===CD/DVD===
To install and boot Privatix with a CD/DVD, simply burn the operating system to a disk and boot from the CD/DVD created when prompted to in the BIOS. While using the Live CD, the user will have access to almost all features of the operating system. However, because no profiles were setup, if the user locks the computer, there will be no way to unlock it as no password was not setup. Note that the main purpose of the live CD/DVD is to install the OS on an external device.

===VirtualBox===
Using VirtualBox requires simply having VirtualBox installed, and when prompted for the installation media to select the .iso file downloaded for Privatix.

When the system starts up select the Live option. This brings up the main Desktop, while using VirtualBox the user will have access to all features available when using Privatix with the Live CD. However there is one small extra level of security, this is provided by the host operating system. this extra layer of security takes the form of the profile system of the host operating system.

===USB===
To install Privatix onto a USB stick, you first must be booted into Privatix Live through a CD/DVD. Then you need to click the install icon on the Desktop to begin installing to a device. It is then possible to select a device for Privatix to install itself on. The installer will ask you if you would like to fill your device with blank data, this makes accessing data/recovering what was originally on the device much harder. The installer will prompt you for a user password, as well as an admin password. The installer will then start it's time consuming process of installing Privatix to the device.

To boot into Privatix from the device, you can stop the computer booting, and then boot into the external device. During booting, Privatix will prompt you for your the password set up during the installation.

==Basic Operation==

===On An External Device===

The main way of utilizing the Privatix Live-System is done by installing the system on an external device. In our case, we used an 8 GB USB stick. When the system is installed on an external device, it is easy to use the system for its intended purpose--having portable anonymous and secure system. We tested this portable version of the system on several laptops with no trouble and no noticeable discretion in use between the different machines. We attempted to use the the system for the following use cases: anonymous web browsing, secure email, data encryption and secure data transportation.

Apart from this, Privatix also came with OpenOffice applications for editing all types of data and much of the basic GNOME functionality, including (but not limited to):
* Pidgin IM and Empathy IM Client for instant messaging
* Evolution Mail for sending and retrieving email
* gedit for text editing

====Anonymous Web Browsing====
[[File:TOR.png|thumb|right|TOR is enabled by default in Privatix]]
The main thing we liked about this system was the secure and anonymous web browsing. The default browser in the system is IceWeasal (an older version of GNU IceCat--a re-branding of FireFox compatible with both Linux and Mac systems) which comes equipped with security features not available by default in FireFox. The main add on that I liked was that The Onion Router (TOR) is installed and enabled by default (it can be disabled if the user wishes). TOR is an open source project meant to provide absolute anonymity online--mainly preventing anyone from learning your location or browsing habits--by routing webpage requests through virtual tunnels made up of individual TOR nodes. Since no two "paths" for a request are ever the same there is no way for your traffic to be monitored. <ref name="TOR Project - About">[https://www.torproject.org/about/overview.html.en TOR Project - About](Last accessed 10-10-11)</ref>

====Secure Email====

The Privatix Live-System also came equipped with the security-conscious email client IceDove--an unbranded ThunderBird mail client (a cross-platform email client that provides government-grade security features). The email client was easily setup and used, supporting digital signing and message encryption via certificates by default (as with TOR, this could be disabled if the user wished). <ref name="icedove">[http://packages.debian.org/sid/icedove IceDove](Last accessed 10-10-11)</ref>

====Data Encryption====
[[File:Encrypt.jpg|thumb|right|Software to encrypt external device]]
The Privatix Live-System also has the ability to encrypt external devices (besides the external device that the system is installed on). This meant that we could have an unlimited amount of encrypted data, not being limited to the size of the external device that the system itself is installed on. The ability to encrypt secondary external devices is very handy as much of the space on the external device that Privatix is installed on is taken up by the system itself, especially if one fills the device with blank decoy data on installation. The encryption software was easily used, well designed and was able to be utilized by absolute beginners of the system.

====Secure Data Transportation====
There are two ways that Privatix fulfills its secure data transportation goal:
# When saving data on the external device with the Privatix Live-System, the data is automatically encrypted and is also password protected (since the portable version of Privatix requires a password to use it). <ref name="Privatix FAQ">[http://www.mandalka.name/privatix/index.html.en Privatix FAQ](Last accessed 10-10-11)</ref>
# As mentioned above, Privatix allows for the encryption of secondary external devices, hence meaning that data can be securely transported without even having the Privatix Live-System with you.

====General Use====

Even with the additional security features not available in other distributions, Privatix would still be a very desirable live system to use. It is portable, especially once installed on an external device, and easily used with little bloatware. The default applications such as OpenOffice for data editing, Pidgin for instant messaging, various graphics editors, video player, and CD burner/extractor ensured that they system was still perfectly functional for everyday use, even with security, not intense functionality, being the main focus.

===Live CD and Virtual Box===

We found that running Privatix using the live CD and VirtualBox was equivalent.

When booting the live CD in VirtualBox, there are certain key features of the Privatix Live-System you are missing (mainly because these features are meant for the portable version to be installed on an external device). However, just booting from the live CD still gives a lot of the functionality I would use the system for--mainly the anonymous web browsing, secure email and data encryption. The key differences were the lack of portability and the inability to save any data on the live CD or VirtualBox environment.

When using only the live CD or VirtualBox all files are deleted when the system is shut down. In addition to, any files saved to the desktop by the user will not appear. They will be hidden from view, but can be viewed by opening the terminal and navigating to the desktop and running the ls command.

The main flaw in only using the system in these mediums is that the added protection of having a user account and password to access the system are no present on the live CD or when using Privatix in a virtual machine. This is due to the fact that Privatix does not implement user accounts and password protection until it has been fully installed onto an external device. As the main goal of this distribution is privacy, it would be highly recommended that the user fully install the OS onto an external device for the added security of password protection.

==Usage Evaluation==

During our use of Privatix, we found it preformed on par for what it was described as, a secure and portable system. The tools provided to encrypt data and the secure browser with add-ons for anonymity especially supported this belief. However we also found some parts of the distribution that were a cause for concern. To begin with, there was a slight language barrier as the system was originally written in German. This was made apparent by the frequent grammar mistakes in both the existing English documentation and the operating system itself indicating that English was not the primary language for the writers of this operating system. Most of the documentation for the operating system is also in German. Those who maintain Privatix and its project website are in the process of translating all their documentation as to be available in both English and German, though currently most of the supporting documentation and FAQ are in German. This made it hard to troubleshoot anything that went wrong with the system during installation or use.

We also noticed that there was no wireless drivers on either portable versions of the OS (installed on an external device or simply using the Live CD or booting up in a virtual machine) so wireless networks could not be connected to. This causes a problem because an operating system on a USB stick should be completely portable, however this driver requires you to have a hard line to use the Internet. It was also noticed that when using Privatix in VirtualBox that even though there was no wireless drivers in Privatix, the wireless capability was provided by the host OS (Windows).

Lastly, when we tried to install Privatix onto a USB it took several attempts. We discovered that to avoid many of the problems we encountered, it is better to use a larger (preferably at least 8GBs) external device for installation and to defer from filling the external device with blank decoy data during installation on an external device.

However once connected to the Internet, all software seems to work as it should. The more basic applications such as OpenOffice, the instant messaging and email clients, multimedia applications etc. function with no problems encountered, working much as they do in any other Linux distribution. The security tools also seem to work as they should. However since we do not know how to test the limits of its security measures we do not know for sure how secure these programs actually are. Overall, Privatix seems to be a very functional and portable distribution, allowing users access to standard applications for tasks such as editing and transporting data, sending/receiving email, instant messaging and multimedia applications with the added bonus of being completely secure and anonymous.

=Part 2=
==Software Packaging==
[[File:dpkg_out.png|thumb|right|Package listing, dpkg]]
[[File:aptitude_out.png|thumb|right|Package listing, aptitude]]
The packaging format that was used for the Privatix-Live System was DEB (based on the Debian packaging format). <ref name="privatix distrowatch">[http://distrowatch.com/table.php?distribution=privatix Privatix Distrowatch Page](Last accessed 12-18-11)</ref> The utilities used with this packaging format were dpkg and aptitude. Dpkg is used as the operating system's package management utility, with aptitude acting as the more user-friendly front end version. Aptitude made finding a list of installed packages quite easy. Aptitude allows you to see a full list of installed packages, with the packages being segregated into categories such as mail, web, shells and utils. As well as using aptitude, the command line can be used to access a list of installed packages. To do this, input the following in terminal and a list of all installed packages is generated. <ref name="dpkg man page">[http://manpages.ubuntu.com/manpages/lucid/man1/dpkg.1.html Dpkg Man Page](Last accessed 12-11-11)</ref>

$ dpkg -l

Though knowing how to do this in command line is useful, we found that using aptitude was generally better as the packages are segregated into categories which made viewing the list of installed packages more simple.

To add a package within Privatix, we found the easiest way was to use the one of the following commands provided by dpkg:

$ dpkg -i <package name>
or
$ dpkg --install <package name>

These commands function in the same way which means they will either install a package, or upgrade already installed versions of the package. <ref name="dpkg man page">[http://manpages.ubuntu.com/manpages/lucid/man1/dpkg.1.html Dpkg Man Page](Last accessed 12-11-11)</ref>

To remove a package within Privatix, we found the easist way was to use either of the following commands provided by dpkg:

$ dpkg -r <package name>
or
$ dpkg -P <package name>

When using "dpkg -r <package name>", everything related to the package ''except'' the configuration files are removed. To fully remove a package, however, we used "dpkg -P <package name>" which removes the entire package, including the configuration files. <ref name="dpkg man page">[http://manpages.ubuntu.com/manpages/lucid/man1/dpkg.1.html Dpkg Man Page](Last accessed 12-11-11)</ref>

We found that the software catalog for this distribution was quite extensive, especially since this distribution is meant to be portable. Privatix includes all the standard packages included with Debian (e.g. libc), as well as several other utilities meant to increase security and privacy while using the system such as IceDove, TOR and TORButton.

==Major Package Versions==

For this section of the report, we needed to speculate as to why a certain ''version'' of a package was included, not just the package itself. We determined, with the release date of Privatix <ref name="privatix distrowatch">[http://distrowatch.com/table.php?distribution=privatix Privatix on Distrowatch](Last accessed 12-19-11)</ref>, that the usual reasoning behind a certain version of a package being included was that the included version was the stable release of the package at that time. We also needed to determine how heavily modified by the distribution's author packages included within our distribution were. However, the distribution's author has stated that everything included is mainly based on Debian. <ref name="privatix documentation">[http://www.mandalka.name/privatix/doc.html Privatix Documentation (German)](Last accessed 12-11-11)</ref> The packages within Privatix have not been modified, the distribution's author has mainly brought together several security and privacy conscious utilities into one distribution for portable and daily use. As such, many of the packages that come with the standard install of Privatix have been included since they are included with the standard install of Debian at the time this distribution was made. Please also note that this reference was taken from the main page of the distribution but that, to view it, you will need to translate it (we used Google translate) as much of the documentation for this distribution is in German.

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th width="10%">
<p align="left">Category</p>
</th>
<th width="15%">
<p align="left">Package</p>
</th>
<th width="10%">
<p align="left">Version</p>
</th>
<th width="15%">
<p align="left">Upstream Source</p>
</th>
<th width="20%">
<p align="left">Vintage</p>
</th>
<th width="30%">
<p align="left">Package Details</p>
</th>
</tr>
<tr>
<td rowspan="3">Kernel</td>
<td>linux-base</td>
<td>2.6.32-31 </td>
<td rowspan="3">None Provided</td>
<td rowspan="3">
This version of the kernel was released in December of 2009, making it just under two years old. <ref name="linux kernel">[http://kernelnewbies.org/Linux_2_6_32 Linux Kernel v2.6.32 Info Page](Last accessed 12-11-11)</ref> The newest stable version of the Linux kernel was released just yesterday (11/11/2011), this version being listed as 3.1.1. <ref name="current kernel">[http://www.kernel.org/ Current Stable Linux Kernel](Last accessed 12-11-11)</ref> This puts the version of the Linux kernel on Privatix as being two years behind the current stable version of the Linux kernel.</td>
<td rowspan="3">
We believe that these packages were included within the distribution as they are the standard packages for the Linux kernel included in the standard install of Debian at the time Privatix was released.</td>
</tr>
<tr>
<td>linux-image-2.6.32-5-686</td>
<td>2.6.32-31</td>
</tr>
<tr>
<td>linux-image-2.6-282</td>
<td>2.6.32+39</td>
</tr>

<tr>
<td rowspan="2">libc</td>
<td>libc-bin</td>
<td rowspan="2">2.11.2-10</td>
<td rowspan="2">http://www.eglibc.org</td>
<td rowspan="2">
This version of libc was released in January 2011, making it approximately 11 months old.<ref name="eglibc">[http://packages.qa.debian.org/e/eglibc.html eglibc Source Package on Debian](Last accessed 12-11-11)</ref> This version is also the current stable version of libc, as listed on Debian. <ref name="eglibc">[http://packages.qa.debian.org/e/eglibc.html eglibc Source Package on Debian](Last accessed 12-11-11)</ref> However, a newer, unstable version (version 2.13-21), is currently undergoing testing.</td>
<td rowspan="2">This package was included as it is also included in the standard install of Debian as well as that all Linux-based systems come with a version of libc.</td>
</tr>
<tr>
<td>libc6</td>
</tr>

<tr>
<td rowspan="1">Shell</td>
<td>bash</td>
<td rowspan="1">4.1-3</td>
<td rowspan="1">http://tiswww.case.edu/php/chet/bash/bashtop.html</td>
<td rowspan="1">This version of bash was released in, approximately, April 2010. <ref name="bash">[http://packages.qa.debian.org/b/bash.html bash Source Package on Debian](Last accessed 12-11-11)</ref> It is also the current stable version of bash. <ref name="bash">[http://packages.qa.debian.org/b/bash.html bash Source Package on Debian](Last accessed 12-11-11)</ref> However, last month, version 4.2 of bash was pushed into testing and became the current experimental version.<ref name="bash">[http://packages.qa.debian.org/b/bash.html bash Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">This package was included as bash is the version of command line included with the standard install of Debian.</td>
</tr>

<tr>
<td rowspan="1">Utilities</td>
<td>busybox</td>
<td rowspan="1">1:1.17.1-8</td>
<td rowspan="1">http://www.qtsoftware.com/</td>
<td rowspan="1">This version of busybox was released in, approximately, November 2010. <ref name="busybox">[http://packages.qa.debian.org/b/busybox.html busybox Source Package on Debian](Last accessed 12-11-11)</ref> It is also the current stable version of busybox as listed on Debian. <ref name="busybox">[http://packages.qa.debian.org/b/busybox.html busybox Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">This package was included as it the version of busybox included with the standard install of Debian.</td>
</tr>
<tr>

<tr>
<td rowspan="1">Software Packaging</td>
<td>dpkg</td>
<td rowspan="1">1.15.8.10</td>
<td rowspan="1">http://wiki.debian.org/Teams/Dpkg</td>
<td rowspan="1">
This version of dpkg was released in February of 2011, making it 10 months old. <ref name="dpkg changelog">[https://launchpad.net/ubuntu/+source/dpkg/1.15.8.10ubuntu1 Dpkg Changelog](Last accessed 12-11-11)</ref> The current stable version of dpkg, as listed on Debian, is version 1.15.8.11 which was released in April of 2011. <ref name="dpkg">[http://packages.qa.debian.org/d/dpkg.html Dpkg Source Package on Debian](Last accessed 12-11-11)</ref> This would put the version of dpkg included with Privatix at 3 months behind the latest stable version.</td>
<td rowspan="1">This package was included since dpkg is the package management system of Debian, the distribution that Privatix is based off of.</td>
</tr>

<tr>
<td rowspan="3">Web Browser</td>
<td>IceWeasel</td>
<td rowspan="1">3.5.16-6</td>
<td rowspan="1">None Provided</td>
<td rowspan="1">
This version of IceWeasel was released in March 2011, making it 9 months old. <ref name="iceweasel">[http://packages.qa.debian.org/i/iceweasel.html IceWeasel Source Package on Debian](Last accessed 12-11-11)</ref> The newest stable version is version 3.5.16-11 which was released in November 2011. <ref name="iceweasel">[http://packages.qa.debian.org/i/iceweasel.html IceWeasel Source Package on Debian](Last accessed 12-11-11)</ref> This would put the version of IceWeasel included with Privatix at 9 months behind the latest stable release.</td>
<td rowspan="1">
IceWeasel was included within this distribution as it is a more security conscious browser than more mainstream browsers such as Mozilla Firefox. IceWeasel, an older version of GNU IceCat (a rebranding of FireFox), comes equipped with security features not available by default in FireFox.</td>
</tr>
<tr>
<td>Tor</td>
<td>0.201029-1</td>
<td>https://www.torproject.org</td>
<td>
This version of TOR was released in January 2011, making it 11 months old. <ref name="tor changelog">[https://launchpad.net/ubuntu/+source/tor/0.2.1.29-1 TOR Changelog](Last accessed 12-11-11)</ref> The latest stable release of TOR is version 0.2.1.30-1 which was released in July 2011. <ref name="tor">[https://launchpad.net/ubuntu/+source/tor TOR on LaunchPad](Last accessed 12-11-11)</ref></td>
<td>
This package was included to help increase security, anonymity and privacy while web browsing which is one of the main goals of the Privatix distribution. For more information on TOR, see the Basic Operation section of the report, under Anonymous Web Browsing. </td>
</tr>
<tr>
<td>TOR Button (xul-ext-torbutton)</td>
<td>1.2.5-3</td>
<td>https://www.torproject.org/torbutton/</td>
<td>
This version of TOR Button was released in October 2010, making it just over a year old.<ref name="torbutton">[https://www.torproject.org/torbutton/ TORButton](Last accessed 12-11-11)</ref> The newest stable version of this program is version 1.4.4.1 which was released last month. <ref name="torbutton">[https://www.torproject.org/torbutton/ TORButton](Last accessed 12-11-11)</ref> This would put the version of TORButton included with Privatix at about a year behind the latest stable release.</td>
<td>
This package was included in order to add to the functionality of TOR. This add-on allows the user to enable and disable TOR with the push of a button, located in the corner of their browser. </td>
</tr>

<tr>
<td rowspan="1">Email</td>
<td>icedove</td>
<td rowspan="1">3.0.11-1+s</td>
<td rowspan="1">None Provided</td>
<td rowspan="1">
This version of IceDove is the current stable version as listed on Debian. <ref name="icedove debian">[http://packages.qadebian.org/i/icedove.html IceDove Source Package on Debian](Last accessed 12-11-11)</ref> However, this version was included within Privatix before it was made stable. It was released as an unstable version in December 2010 and was later released as the current stable version in October 2011. <ref name="icedove debian">[http://packages.qadebian.org/i/icedove.html IceDove Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">
This email client was included due to the fact that it is a more security-conscious email client, providing government-grade security features, than others such as the regular version of ThunderBird. For more information on this program, refer to the Basic Operation section of this report under Secure Email.</td>
</tr>

<tr>
<td rowspan="1">Other</td>
<td>pidgin</td>
<td rowspan="1">2.7.3.1+sq</td>
<td rowspan="1">http://www.pidgin.im</td>
<td rowspan="1">
This version of the Pidgin was released in October 2010, and is also the current stable version of Pidgin as listed on Debian. <ref name="pidgin">[http://packages.qa.debian.org/p/pidgin.html Pidgin Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">
This package was included as Pidgin is the default IM client included with the standard install of Debian, the system on which Privatix is based.</td>
</tr>
</table>

==Initialization==

Privatix generally follows the same initialization process as Debian. Privatix initializes by first executing first the BIOS then the boot loader code. <ref name="debian boot process">[http://wiki.debian.org/BootProcess#System_Initialization Debian Boot Process](Last accessed 12-11-11)</ref> Privatix uses the same boot loader as Debian which is System V initialization. /etc/inittab is the configuration file, with the /sbin/init program initializing the system following the description in this configuration file. <ref name="debian boot process">[http://wiki.debian.org/BootProcess#System_Initialization Debian Boot Process](Last accessed 12-11-11)</ref> inittab will set the default run level of Privatix, which is run level 2. Following this, all the scripts located in /etc/rc2.d are executed alphabetically. <ref name="debian boot process">[http://wiki.debian.org/BootProcess#System_Initialization Debian Boot Process](Last accessed 12-11-11)</ref> These scripts are:

[[File:pstree1.png|thumb|right|Process tree after start up]]
[[File:pstree_.png|thumb|right|Process tree after start up cont.]]

* '''S01polipo''': polipo web cache--a small and fast caching web proxy
* '''S01rsyslog''': enhanced multi-thread syslogd which is Linux system logging utility
* '''S01sudo''': provides sudo
* '''S02cron''': starts the scheduler of the system
* '''S02dbus''': utility to send messages between processes and applications
* '''S02rsync''': opens rsync--a program that allows files to be copied to and from remote machines
* '''S02tor''': starts TOR (for more information, see above)
* '''S03avahi-daemon''': starts the zeroconf daemon which is used for configuring the network automatically
* '''S03bluetooth''': launches bluetooth
* '''S03networ-manager''': starts a daemon that automatically switches network connections to the best available connection
* '''S04openvpn''': starts openvpn service--a generic vpn service
* '''S05gdm3''': script for the GNOME display manager
* '''S06bootlogs''': the log file handling to be done during bootup--mainly things that don't need to be done particularly early in the boot process
* '''S07rc.local''': runs the /etc/rc.local file if it exists--by default this script does nothing, it is used only to exit
* '''S07rmologin''': removes the /etc/nologin file as the last step in the boot process
* '''S07stop-bootlogd''': runs the /etc/rc.local file again, if it exists--by default this script does nothing, it is used only to exit

Following this, the system is initialized. The processes running on the newly initialized system and what initializes them are as follows:

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr>
<th width="20%"> <b>Process Name</b> </th>
<th width="60%"> <b>Description</b> </th>
<th width="20%"> <b>Initialized By</b> </th>
</tr>
<tr>
<td> NetworkManager </td>
<td> Daemon that automatically switches network connections to the best available connection </td>
<td> S03networ-manager init script </td>
</tr>

<tr>
<td> avahi-daemon </td>
<td> zeroconf daemon which is used for configuring the network automatically </td>
<td> S03avahi-daemon init script </td>
</tr>

<tr>
<td> bluetoothd </td>
<td> Enables bluetooth to be used </td>
<td> S03bluetooth init script </td>
</tr>

<tr>
<td> cron </td>
<td> Scheduler of Debian systems </td>
<td> S02cron init script </td>
</tr>

<tr>
<td> dbus-launch </td>
<td> Utility to send messages between processes and applications </td>
<td> S02dbus init script </td>
</tr>

<tr>
<td> gdm3 </td>
<td rowspan="4"> GNOME display manager </td>
<td rowspan="4"> S05gdm3 init script </td>
</tr>

<tr>
<td> gnome-screensav </td>
</tr>

<tr>
<td> gnome-settings- </td>
</tr>

<tr>
<td> gnome-terminal </td>
</tr>

<tr>
<td> polipo </td>
<td> polipo web cache--a small and fast caching web proxy </td>
<td> S01polipo init script </td>
</tr>

<tr>
<td> polkitd </td>
<td> Polkit is an application level toolkit to allow unprivileged and privileged processes talk to one another. <ref name="polkit">[http://live.gnome.org/Seahorse Polkit](Last accessed 12-18-11)</ref></td>
<td> IB </td>
</tr>

<tr>
<td> tor </td>
<td> TOR is an open source project meant to provide anonymity online--mainly preventing anyone from learning your location or browsing habits--by routing webpage requests through virtual tunnels made up of individual TOR nodes. Since no two "paths" for a request are ever the same there is no way for your traffic to be monitored. </td>
<td> S02tor init script </td>
</tr>

</table>

We found this information by first confirming that Privatix used the same style of initializing as Debian. Once we ascertained this, we researched the Debian boot process. Privatix followed the same steps up until the loading of the scripts, which had some scripts that differed from Debian (e.g. TOR). Following this, we researched each of the scripts run on Privatix's default boot level of 2. The scripts are listed above, in the order they execute. To find the purpose of each of the scripts and what programs they opened, we manually went through each of the scripts. To find the processes running on the newly initialized system, we used the command "ps tree". Once we had a list of the running processes, we researched the purpose of each process. To find how each process was initialized, we manually searched through the initialization scripts and matched each process with their initialization script.

=References=

<references />

COMP 3000 2011 Report: Privatix

2011-12-19T22:41:47Z

Gbooth: /* Major Package Versions */

=Part 1=

==Background==

The name of our chosen distribution is the Privatix Live-System. The target audience for this system are people that are concerned about privacy, anonymity and security when web-surfing, transporting/editing sensitive data, sending email etc. Therefore, the goals of this distribution are mainly security and privacy related which means being able to provide security-conscious tools and applications integrated into a portable Operating System (OS) for anyone to use at any time. The distribution is meant to be portable, coming in the form of a live Compact Diak (CD) which can be installed on an external device or a Universal Serial Bus (USB) flash drive with an encrypted password to ensure that all your data remains private, even if your external device is lost or compromised. It should be noted that the live CD is only meant for installing the OS onto a USB in order to provide a portable, privacy conscious OS. The user should not solely rely on the live CD as the OS does not yet implement password protection. This is due to the fact that there are no user accounts on the live CD, user accounts are only implemented once the full OS is installed on a USB. The Privatix Live-System incorporates many security-conscious tools for safe editing, carrying sensitive data, encrypted communication and anonymous web surfing such as built in software to encrypt external devices, IceWeasel and TOR. <ref name="privatix home">[http://www.mandalka.name/privatix/index.html.en Privatix home page](Last accessed 10-10-11)</ref>

This Privatix Live-System was developed in Germany by Markus Mandalka. It may be obtained by going to Markus Mandalka's website and navigating to the download page ([http://www.mandalka.name/privatix/download.html.en Mandalka]), selecting the version you wish to download (we chose the English version) and downloading it. The approximate size of the Privatix Live-System is 838 Megabytes (MB) for the full English version (there are smaller versions available which have had features such as GNOME removed).<ref name="Privatix download page">[http://www.mandalka.name/privatix/download.html.en Privatix download page](Last accessed 10-10-11)</ref>. The Privatix Live-System was based off of Debian ([http://distrowatch.com/table.php?distribution=debian Debian]).

==Installation/Startup==
[[File:PrivatixBoot.png|thumb|right|Privatix boot screen]]
[[File:PrivatixDesktop.png|thumb|right|Privatix desktop]]
Currently we have Privatix installed on an 8 Gigabyte (GB) USB stick in order to utilize the full power of the OS. However, Privatix can be used in a few ways other than installing it on an external device such as on a live CD/Digital Video Disk (DVD), or in a virtualized environment such as VirtualBox. It should be noted, however, that the full potential of the OS is only unlocked once the OS has been installed on an external device as it was meant to be. One main flaw in using either a virtual environment or the live CD is that user accounts, and hence password protection, are not implemented until the OS has been installed on an external device.

To install the Privatix-Live System, the user must first download the .iso from the download page ([http://www.mandalka.name/privatix/download.html.en Mandalka]). Once the .iso file is downloaded, it is possible to either burn the operating system to a CD/DVD, use VirtualBox, or install it to a USB stick.

===CD/DVD===
To install and boot Privatix with a CD/DVD, simply burn the operating system to a disk and boot from the CD/DVD created when prompted to in the BIOS. While using the Live CD, the user will have access to almost all features of the operating system. However, because no profiles were setup, if the user locks the computer, there will be no way to unlock it as no password was not setup. Note that the main purpose of the live CD/DVD is to install the OS on an external device.

===VirtualBox===
Using VirtualBox requires simply having VirtualBox installed, and when prompted for the installation media to select the .iso file downloaded for Privatix.

When the system starts up select the Live option. This brings up the main Desktop, while using VirtualBox the user will have access to all features available when using Privatix with the Live CD. However there is one small extra level of security, this is provided by the host operating system. this extra layer of security takes the form of the profile system of the host operating system.

===USB===
To install Privatix onto a USB stick, you first must be booted into Privatix Live through a CD/DVD. Then you need to click the install icon on the Desktop to begin installing to a device. It is then possible to select a device for Privatix to install itself on. The installer will ask you if you would like to fill your device with blank data, this makes accessing data/recovering what was originally on the device much harder. The installer will prompt you for a user password, as well as an admin password. The installer will then start it's time consuming process of installing Privatix to the device.

To boot into Privatix from the device, you can stop the computer booting, and then boot into the external device. During booting, Privatix will prompt you for your the password set up during the installation.

==Basic Operation==

===On An External Device===

The main way of utilizing the Privatix Live-System is done by installing the system on an external device. In our case, we used an 8 GB USB stick. When the system is installed on an external device, it is easy to use the system for its intended purpose--having portable anonymous and secure system. We tested this portable version of the system on several laptops with no trouble and no noticeable discretion in use between the different machines. We attempted to use the the system for the following use cases: anonymous web browsing, secure email, data encryption and secure data transportation.

Apart from this, Privatix also came with OpenOffice applications for editing all types of data and much of the basic GNOME functionality, including (but not limited to):
* Pidgin IM and Empathy IM Client for instant messaging
* Evolution Mail for sending and retrieving email
* gedit for text editing

====Anonymous Web Browsing====
[[File:TOR.png|thumb|right|TOR is enabled by default in Privatix]]
The main thing we liked about this system was the secure and anonymous web browsing. The default browser in the system is IceWeasal (an older version of GNU IceCat--a re-branding of FireFox compatible with both Linux and Mac systems) which comes equipped with security features not available by default in FireFox. The main add on that I liked was that The Onion Router (TOR) is installed and enabled by default (it can be disabled if the user wishes). TOR is an open source project meant to provide absolute anonymity online--mainly preventing anyone from learning your location or browsing habits--by routing webpage requests through virtual tunnels made up of individual TOR nodes. Since no two "paths" for a request are ever the same there is no way for your traffic to be monitored. <ref name="TOR Project - About">[https://www.torproject.org/about/overview.html.en TOR Project - About](Last accessed 10-10-11)</ref>

====Secure Email====

The Privatix Live-System also came equipped with the security-conscious email client IceDove--an unbranded ThunderBird mail client (a cross-platform email client that provides government-grade security features). The email client was easily setup and used, supporting digital signing and message encryption via certificates by default (as with TOR, this could be disabled if the user wished). <ref name="icedove">[http://packages.debian.org/sid/icedove IceDove](Last accessed 10-10-11)</ref>

====Data Encryption====
[[File:Encrypt.jpg|thumb|right|Software to encrypt external device]]
The Privatix Live-System also has the ability to encrypt external devices (besides the external device that the system is installed on). This meant that we could have an unlimited amount of encrypted data, not being limited to the size of the external device that the system itself is installed on. The ability to encrypt secondary external devices is very handy as much of the space on the external device that Privatix is installed on is taken up by the system itself, especially if one fills the device with blank decoy data on installation. The encryption software was easily used, well designed and was able to be utilized by absolute beginners of the system.

====Secure Data Transportation====
There are two ways that Privatix fulfills its secure data transportation goal:
# When saving data on the external device with the Privatix Live-System, the data is automatically encrypted and is also password protected (since the portable version of Privatix requires a password to use it). <ref name="Privatix FAQ">[http://www.mandalka.name/privatix/index.html.en Privatix FAQ](Last accessed 10-10-11)</ref>
# As mentioned above, Privatix allows for the encryption of secondary external devices, hence meaning that data can be securely transported without even having the Privatix Live-System with you.

====General Use====

Even with the additional security features not available in other distributions, Privatix would still be a very desirable live system to use. It is portable, especially once installed on an external device, and easily used with little bloatware. The default applications such as OpenOffice for data editing, Pidgin for instant messaging, various graphics editors, video player, and CD burner/extractor ensured that they system was still perfectly functional for everyday use, even with security, not intense functionality, being the main focus.

===Live CD and Virtual Box===

We found that running Privatix using the live CD and VirtualBox was equivalent.

When booting the live CD in VirtualBox, there are certain key features of the Privatix Live-System you are missing (mainly because these features are meant for the portable version to be installed on an external device). However, just booting from the live CD still gives a lot of the functionality I would use the system for--mainly the anonymous web browsing, secure email and data encryption. The key differences were the lack of portability and the inability to save any data on the live CD or VirtualBox environment.

When using only the live CD or VirtualBox all files are deleted when the system is shut down. In addition to, any files saved to the desktop by the user will not appear. They will be hidden from view, but can be viewed by opening the terminal and navigating to the desktop and running the ls command.

The main flaw in only using the system in these mediums is that the added protection of having a user account and password to access the system are no present on the live CD or when using Privatix in a virtual machine. This is due to the fact that Privatix does not implement user accounts and password protection until it has been fully installed onto an external device. As the main goal of this distribution is privacy, it would be highly recommended that the user fully install the OS onto an external device for the added security of password protection.

==Usage Evaluation==

During our use of Privatix, we found it preformed on par for what it was described as, a secure and portable system. The tools provided to encrypt data and the secure browser with add-ons for anonymity especially supported this belief. However we also found some parts of the distribution that were a cause for concern. To begin with, there was a slight language barrier as the system was originally written in German. This was made apparent by the frequent grammar mistakes in both the existing English documentation and the operating system itself indicating that English was not the primary language for the writers of this operating system. Most of the documentation for the operating system is also in German. Those who maintain Privatix and its project website are in the process of translating all their documentation as to be available in both English and German, though currently most of the supporting documentation and FAQ are in German. This made it hard to troubleshoot anything that went wrong with the system during installation or use.

We also noticed that there was no wireless drivers on either portable versions of the OS (installed on an external device or simply using the Live CD or booting up in a virtual machine) so wireless networks could not be connected to. This causes a problem because an operating system on a USB stick should be completely portable, however this driver requires you to have a hard line to use the Internet. It was also noticed that when using Privatix in VirtualBox that even though there was no wireless drivers in Privatix, the wireless capability was provided by the host OS (Windows).

Lastly, when we tried to install Privatix onto a USB it took several attempts. We discovered that to avoid many of the problems we encountered, it is better to use a larger (preferably at least 8GBs) external device for installation and to defer from filling the external device with blank decoy data during installation on an external device.

However once connected to the Internet, all software seems to work as it should. The more basic applications such as OpenOffice, the instant messaging and email clients, multimedia applications etc. function with no problems encountered, working much as they do in any other Linux distribution. The security tools also seem to work as they should. However since we do not know how to test the limits of its security measures we do not know for sure how secure these programs actually are. Overall, Privatix seems to be a very functional and portable distribution, allowing users access to standard applications for tasks such as editing and transporting data, sending/receiving email, instant messaging and multimedia applications with the added bonus of being completely secure and anonymous.

=Part 2=
==Software Packaging==
[[File:dpkg_out.png|thumb|right|Package listing, dpkg]]
[[File:aptitude_out.png|thumb|right|Package listing, aptitude]]
The packaging format that was used for the Privatix-Live System was DEB (based on the Debian packaging format). <ref name="privatix distrowatch">[http://distrowatch.com/table.php?distribution=privatix Privatix Distrowatch Page](Last accessed 12-11-11)</ref> The utilities used with this packaging format were dpkg and aptitude. Dpkg is used as the operating system's package management utility, with aptitude acting as the more user-friendly front end version. Aptitude made finding a list of installed packages quite easy. Aptitude allows you to see a full list of installed packages, with the packages being segregated into categories such as mail, web, shells and utils. As well as using aptitude, the command line can be used to access a list of installed packages. To do this, input the following in terminal and a list of all installed packages is generated. <ref name="dpkg man page">[http://manpages.ubuntu.com/manpages/lucid/man1/dpkg.1.html Dpkg Man Page](Last accessed 12-11-11)</ref>

$ dpkg -l

Though knowing how to do this in command line is useful, we found that using aptitude was generally better as the packages are segregated into categories which made viewing the list of installed packages more simple.

To add a package within Privatix, we found the easiest way was to use the one of the following commands provided by dpkg:

$ dpkg -i <package name>
or
$ dpkg --install <package name>

These commands function in the same way which means they will either install a package, or upgrade already installed versions of the package. <ref name="dpkg man page">[http://manpages.ubuntu.com/manpages/lucid/man1/dpkg.1.html Dpkg Man Page](Last accessed 12-11-11)</ref>

To remove a package within Privatix, we found the easist way was to use either of the following commands provided by dpkg:

$ dpkg -r <package name>
or
$ dpkg -P <package name>

When using "dpkg -r <package name>", everything related to the package ''except'' the configuration files are removed. To fully remove a package, however, we used "dpkg -P <package name>" which removes the entire package, including the configuration files. <ref name="dpkg man page">[http://manpages.ubuntu.com/manpages/lucid/man1/dpkg.1.html Dpkg Man Page](Last accessed 12-11-11)</ref>

We found that the software catalog for this distribution was quite extensive, especially since this distribution is meant to be portable. Privatix includes all the standard packages included with Debian (e.g. libc), as well as several other utilities meant to increase security and privacy while using the system such as IceDove, TOR and TORButton.

==Major Package Versions==

For this section of the report, we needed to speculate as to why a certain ''version'' of a package was included, not just the package itself. We determined, with the release date of Privatix <ref name="privatix distrowatch">[http://distrowatch.com/table.php?distribution=privatix Privatix on Distrowatch](Last accessed 12-19-11)</ref>, that the usual reasoning behind a certain version of a package being included was that the included version was the stable release of the package at that time. We also needed to determine how heavily modified by the distribution's author packages included within our distribution were. However, the distribution's author has stated that everything included is mainly based on Debian. <ref name="privatix documentation">[http://www.mandalka.name/privatix/doc.html Privatix Documentation (German)](Last accessed 12-11-11)</ref> The packages within Privatix have not been modified, the distribution's author has mainly brought together several security and privacy conscious utilities into one distribution for portable and daily use. As such, many of the packages that come with the standard install of Privatix have been included since they are included with the standard install of Debian at the time this distribution was made. Please also note that this reference was taken from the main page of the distribution but that, to view it, you will need to translate it (we used Google translate) as much of the documentation for this distribution is in German.

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th width="10%">
<p align="left">Category</p>
</th>
<th width="15%">
<p align="left">Package</p>
</th>
<th width="10%">
<p align="left">Version</p>
</th>
<th width="15%">
<p align="left">Upstream Source</p>
</th>
<th width="20%">
<p align="left">Vintage</p>
</th>
<th width="30%">
<p align="left">Package Details</p>
</th>
</tr>
<tr>
<td rowspan="3">Kernel</td>
<td>linux-base</td>
<td>2.6.32-31 </td>
<td rowspan="3">None Provided</td>
<td rowspan="3">
This version of the kernel was released in December of 2009, making it just under two years old. <ref name="linux kernel">[http://kernelnewbies.org/Linux_2_6_32 Linux Kernel v2.6.32 Info Page](Last accessed 12-11-11)</ref> The newest stable version of the Linux kernel was released just yesterday (11/11/2011), this version being listed as 3.1.1. <ref name="current kernel">[http://www.kernel.org/ Current Stable Linux Kernel](Last accessed 12-11-11)</ref> This puts the version of the Linux kernel on Privatix as being two years behind the current stable version of the Linux kernel.</td>
<td rowspan="3">
We believe that these packages were included within the distribution as they are the standard packages for the Linux kernel included in the standard install of Debian at the time Privatix was released.</td>
</tr>
<tr>
<td>linux-image-2.6.32-5-686</td>
<td>2.6.32-31</td>
</tr>
<tr>
<td>linux-image-2.6-282</td>
<td>2.6.32+39</td>
</tr>

<tr>
<td rowspan="2">libc</td>
<td>libc-bin</td>
<td rowspan="2">2.11.2-10</td>
<td rowspan="2">http://www.eglibc.org</td>
<td rowspan="2">
This version of libc was released in January 2011, making it approximately 11 months old.<ref name="eglibc">[http://packages.qa.debian.org/e/eglibc.html eglibc Source Package on Debian](Last accessed 12-11-11)</ref> This version is also the current stable version of libc, as listed on Debian. <ref name="eglibc">[http://packages.qa.debian.org/e/eglibc.html eglibc Source Package on Debian](Last accessed 12-11-11)</ref> However, a newer, unstable version (version 2.13-21), is currently undergoing testing.</td>
<td rowspan="2">This package was included as it is also included in the standard install of Debian as well as that all Linux-based systems come with a version of libc.</td>
</tr>
<tr>
<td>libc6</td>
</tr>

<tr>
<td rowspan="1">Shell</td>
<td>bash</td>
<td rowspan="1">4.1-3</td>
<td rowspan="1">http://tiswww.case.edu/php/chet/bash/bashtop.html</td>
<td rowspan="1">This version of bash was released in, approximately, April 2010. <ref name="bash">[http://packages.qa.debian.org/b/bash.html bash Source Package on Debian](Last accessed 12-11-11)</ref> It is also the current stable version of bash. <ref name="bash">[http://packages.qa.debian.org/b/bash.html bash Source Package on Debian](Last accessed 12-11-11)</ref> However, last month, version 4.2 of bash was pushed into testing and became the current experimental version.<ref name="bash">[http://packages.qa.debian.org/b/bash.html bash Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">This package was included as bash is the version of command line included with the standard install of Debian.</td>
</tr>

<tr>
<td rowspan="1">Utilities</td>
<td>busybox</td>
<td rowspan="1">1:1.17.1-8</td>
<td rowspan="1">http://www.qtsoftware.com/</td>
<td rowspan="1">This version of busybox was released in, approximately, November 2010. <ref name="busybox">[http://packages.qa.debian.org/b/busybox.html busybox Source Package on Debian](Last accessed 12-11-11)</ref> It is also the current stable version of busybox as listed on Debian. <ref name="busybox">[http://packages.qa.debian.org/b/busybox.html busybox Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">This package was included as it the version of busybox included with the standard install of Debian.</td>
</tr>
<tr>

<tr>
<td rowspan="1">Software Packaging</td>
<td>dpkg</td>
<td rowspan="1">1.15.8.10</td>
<td rowspan="1">http://wiki.debian.org/Teams/Dpkg</td>
<td rowspan="1">
This version of dpkg was released in February of 2011, making it 10 months old. <ref name="dpkg changelog">[https://launchpad.net/ubuntu/+source/dpkg/1.15.8.10ubuntu1 Dpkg Changelog](Last accessed 12-11-11)</ref> The current stable version of dpkg, as listed on Debian, is version 1.15.8.11 which was released in April of 2011. <ref name="dpkg">[http://packages.qa.debian.org/d/dpkg.html Dpkg Source Package on Debian](Last accessed 12-11-11)</ref> This would put the version of dpkg included with Privatix at 3 months behind the latest stable version.</td>
<td rowspan="1">This package was included since dpkg is the package management system of Debian, the distribution that Privatix is based off of.</td>
</tr>

<tr>
<td rowspan="3">Web Browser</td>
<td>IceWeasel</td>
<td rowspan="1">3.5.16-6</td>
<td rowspan="1">None Provided</td>
<td rowspan="1">
This version of IceWeasel was released in March 2011, making it 9 months old. <ref name="iceweasel">[http://packages.qa.debian.org/i/iceweasel.html IceWeasel Source Package on Debian](Last accessed 12-11-11)</ref> The newest stable version is version 3.5.16-11 which was released in November 2011. <ref name="iceweasel">[http://packages.qa.debian.org/i/iceweasel.html IceWeasel Source Package on Debian](Last accessed 12-11-11)</ref> This would put the version of IceWeasel included with Privatix at 9 months behind the latest stable release.</td>
<td rowspan="1">
IceWeasel was included within this distribution as it is a more security conscious browser than more mainstream browsers such as Mozilla Firefox. IceWeasel, an older version of GNU IceCat (a rebranding of FireFox), comes equipped with security features not available by default in FireFox.</td>
</tr>
<tr>
<td>Tor</td>
<td>0.201029-1</td>
<td>https://www.torproject.org</td>
<td>
This version of TOR was released in January 2011, making it 11 months old. <ref name="tor changelog">[https://launchpad.net/ubuntu/+source/tor/0.2.1.29-1 TOR Changelog](Last accessed 12-11-11)</ref> The latest stable release of TOR is version 0.2.1.30-1 which was released in July 2011. <ref name="tor">[https://launchpad.net/ubuntu/+source/tor TOR on LaunchPad](Last accessed 12-11-11)</ref></td>
<td>
This package was included to help increase security, anonymity and privacy while web browsing which is one of the main goals of the Privatix distribution. For more information on TOR, see the Basic Operation section of the report, under Anonymous Web Browsing. </td>
</tr>
<tr>
<td>TOR Button (xul-ext-torbutton)</td>
<td>1.2.5-3</td>
<td>https://www.torproject.org/torbutton/</td>
<td>
This version of TOR Button was released in October 2010, making it just over a year old.<ref name="torbutton">[https://www.torproject.org/torbutton/ TORButton](Last accessed 12-11-11)</ref> The newest stable version of this program is version 1.4.4.1 which was released last month. <ref name="torbutton">[https://www.torproject.org/torbutton/ TORButton](Last accessed 12-11-11)</ref> This would put the version of TORButton included with Privatix at about a year behind the latest stable release.</td>
<td>
This package was included in order to add to the functionality of TOR. This add-on allows the user to enable and disable TOR with the push of a button, located in the corner of their browser. </td>
</tr>

<tr>
<td rowspan="1">Email</td>
<td>icedove</td>
<td rowspan="1">3.0.11-1+s</td>
<td rowspan="1">None Provided</td>
<td rowspan="1">
This version of IceDove is the current stable version as listed on Debian. <ref name="icedove debian">[http://packages.qadebian.org/i/icedove.html IceDove Source Package on Debian](Last accessed 12-11-11)</ref> However, this version was included within Privatix before it was made stable. It was released as an unstable version in December 2010 and was later released as the current stable version in October 2011. <ref name="icedove debian">[http://packages.qadebian.org/i/icedove.html IceDove Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">
This email client was included due to the fact that it is a more security-conscious email client, providing government-grade security features, than others such as the regular version of ThunderBird. For more information on this program, refer to the Basic Operation section of this report under Secure Email.</td>
</tr>

<tr>
<td rowspan="1">Other</td>
<td>pidgin</td>
<td rowspan="1">2.7.3.1+sq</td>
<td rowspan="1">http://www.pidgin.im</td>
<td rowspan="1">
This version of the Pidgin was released in October 2010, and is also the current stable version of Pidgin as listed on Debian. <ref name="pidgin">[http://packages.qa.debian.org/p/pidgin.html Pidgin Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">
This package was included as Pidgin is the default IM client included with the standard install of Debian, the system on which Privatix is based.</td>
</tr>
</table>

==Initialization==

Privatix generally follows the same initialization process as Debian. Privatix initializes by first executing first the BIOS then the boot loader code. <ref name="debian boot process">[http://wiki.debian.org/BootProcess#System_Initialization Debian Boot Process](Last accessed 12-11-11)</ref> Privatix uses the same boot loader as Debian which is System V initialization. /etc/inittab is the configuration file, with the /sbin/init program initializing the system following the description in this configuration file. <ref name="debian boot process">[http://wiki.debian.org/BootProcess#System_Initialization Debian Boot Process](Last accessed 12-11-11)</ref> inittab will set the default run level of Privatix, which is run level 2. Following this, all the scripts located in /etc/rc2.d are executed alphabetically. <ref name="debian boot process">[http://wiki.debian.org/BootProcess#System_Initialization Debian Boot Process](Last accessed 12-11-11)</ref> These scripts are:

[[File:pstree1.png|thumb|right|Process tree after start up]]
[[File:pstree_.png|thumb|right|Process tree after start up cont.]]

* '''S01polipo''': polipo web cache--a small and fast caching web proxy
* '''S01rsyslog''': enhanced multi-thread syslogd which is Linux system logging utility
* '''S01sudo''': provides sudo
* '''S02cron''': starts the scheduler of the system
* '''S02dbus''': utility to send messages between processes and applications
* '''S02rsync''': opens rsync--a program that allows files to be copied to and from remote machines
* '''S02tor''': starts TOR (for more information, see above)
* '''S03avahi-daemon''': starts the zeroconf daemon which is used for configuring the network automatically
* '''S03bluetooth''': launches bluetooth
* '''S03networ-manager''': starts a daemon that automatically switches network connections to the best available connection
* '''S04openvpn''': starts openvpn service--a generic vpn service
* '''S05gdm3''': script for the GNOME display manager
* '''S06bootlogs''': the log file handling to be done during bootup--mainly things that don't need to be done particularly early in the boot process
* '''S07rc.local''': runs the /etc/rc.local file if it exists--by default this script does nothing, it is used only to exit
* '''S07rmologin''': removes the /etc/nologin file as the last step in the boot process
* '''S07stop-bootlogd''': runs the /etc/rc.local file again, if it exists--by default this script does nothing, it is used only to exit

Following this, the system is initialized. The processes running on the newly initialized system and what initializes them are as follows:

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr>
<th width="20%"> <b>Process Name</b> </th>
<th width="60%"> <b>Description</b> </th>
<th width="20%"> <b>Initialized By</b> </th>
</tr>
<tr>
<td> NetworkManager </td>
<td> Daemon that automatically switches network connections to the best available connection </td>
<td> S03networ-manager init script </td>
</tr>

<tr>
<td> avahi-daemon </td>
<td> zeroconf daemon which is used for configuring the network automatically </td>
<td> S03avahi-daemon init script </td>
</tr>

<tr>
<td> bluetoothd </td>
<td> Enables bluetooth to be used </td>
<td> S03bluetooth init script </td>
</tr>

<tr>
<td> cron </td>
<td> Scheduler of Debian systems </td>
<td> S02cron init script </td>
</tr>

<tr>
<td> dbus-launch </td>
<td> Utility to send messages between processes and applications </td>
<td> S02dbus init script </td>
</tr>

<tr>
<td> gdm3 </td>
<td rowspan="4"> GNOME display manager </td>
<td rowspan="4"> S05gdm3 init script </td>
</tr>

<tr>
<td> gnome-screensav </td>
</tr>

<tr>
<td> gnome-settings- </td>
</tr>

<tr>
<td> gnome-terminal </td>
</tr>

<tr>
<td> polipo </td>
<td> polipo web cache--a small and fast caching web proxy </td>
<td> S01polipo init script </td>
</tr>

<tr>
<td> polkitd </td>
<td> Polkit is an application level toolkit to allow unprivileged and privileged processes talk to one another. <ref name="polkit">[http://live.gnome.org/Seahorse Polkit](Last accessed 12-18-11)</ref></td>
<td> IB </td>
</tr>

<tr>
<td> tor </td>
<td> TOR is an open source project meant to provide anonymity online--mainly preventing anyone from learning your location or browsing habits--by routing webpage requests through virtual tunnels made up of individual TOR nodes. Since no two "paths" for a request are ever the same there is no way for your traffic to be monitored. </td>
<td> S02tor init script </td>
</tr>

</table>

We found this information by first confirming that Privatix used the same style of initializing as Debian. Once we ascertained this, we researched the Debian boot process. Privatix followed the same steps up until the loading of the scripts, which had some scripts that differed from Debian (e.g. TOR). Following this, we researched each of the scripts run on Privatix's default boot level of 2. The scripts are listed above, in the order they execute. To find the purpose of each of the scripts and what programs they opened, we manually went through each of the scripts. To find the processes running on the newly initialized system, we used the command "ps tree". Once we had a list of the running processes, we researched the purpose of each process. To find how each process was initialized, we manually searched through the initialization scripts and matched each process with their initialization script.

=References=

<references />

COMP 3000 2011 Report: Privatix

2011-12-19T02:35:16Z

Gbooth: /* Initialization */

=Part 1=

==Background==

The name of our chosen distribution is the Privatix Live-System. The target audience for this system are people that are concerned about privacy, anonymity and security when web-surfing, transporting/editing sensitive data, sending email etc. Therefore, the goals of this distribution are mainly security and privacy related which means being able to provide security-conscious tools and applications integrated into a portable Operating System (OS) for anyone to use at any time. The distribution is meant to be portable, coming in the form of a live Compact Diak (CD) which can be installed on an external device or a Universal Serial Bus (USB) flash drive with an encrypted password to ensure that all your data remains private, even if your external device is lost or compromised. It should be noted that the live CD is only meant for installing the OS onto a USB in order to provide a portable, privacy conscious OS. The user should not solely rely on the live CD as the OS does not yet implement password protection. This is due to the fact that there are no user accounts on the live CD, user accounts are only implemented once the full OS is installed on a USB. The Privatix Live-System incorporates many security-conscious tools for safe editing, carrying sensitive data, encrypted communication and anonymous web surfing such as built in software to encrypt external devices, IceWeasel and TOR. <ref name="privatix home">[http://www.mandalka.name/privatix/index.html.en Privatix home page](Last accessed 10-10-11)</ref>

This Privatix Live-System was developed in Germany by Markus Mandalka. It may be obtained by going to Markus Mandalka's website and navigating to the download page ([http://www.mandalka.name/privatix/download.html.en Mandalka]), selecting the version you wish to download (we chose the English version) and downloading it. The approximate size of the Privatix Live-System is 838 Megabytes (MB) for the full English version (there are smaller versions available which have had features such as GNOME removed).<ref name="Privatix download page">[http://www.mandalka.name/privatix/download.html.en Privatix download page](Last accessed 10-10-11)</ref>. The Privatix Live-System was based off of Debian ([http://distrowatch.com/table.php?distribution=debian Debian]).

==Installation/Startup==
[[File:PrivatixBoot.png|thumb|right|Privatix boot screen]]
[[File:PrivatixDesktop.png|thumb|right|Privatix desktop]]
Currently we have Privatix installed on an 8 Gigabyte (GB) USB stick in order to utilize the full power of the OS. However, Privatix can be used in a few ways other than installing it on an external device such as on a live CD/Digital Video Disk (DVD), or in a virtualized environment such as VirtualBox. It should be noted, however, that the full potential of the OS is only unlocked once the OS has been installed on an external device as it was meant to be. One main flaw in using either a virtual environment or the live CD is that user accounts, and hence password protection, are not implemented until the OS has been installed on an external device.

To install the Privatix-Live System, the user must first download the .iso from the download page ([http://www.mandalka.name/privatix/download.html.en Mandalka]). Once the .iso file is downloaded, it is possible to either burn the operating system to a CD/DVD, use VirtualBox, or install it to a USB stick.

===CD/DVD===
To install and boot Privatix with a CD/DVD, simply burn the operating system to a disk and boot from the CD/DVD created when prompted to in the BIOS. While using the Live CD, the user will have access to almost all features of the operating system. However, because no profiles were setup, if the user locks the computer, there will be no way to unlock it as no password was not setup. Note that the main purpose of the live CD/DVD is to install the OS on an external device.

===VirtualBox===
Using VirtualBox requires simply having VirtualBox installed, and when prompted for the installation media to select the .iso file downloaded for Privatix.

When the system starts up select the Live option. This brings up the main Desktop, while using VirtualBox the user will have access to all features available when using Privatix with the Live CD. However there is one small extra level of security, this is provided by the host operating system. this extra layer of security takes the form of the profile system of the host operating system.

===USB===
To install Privatix onto a USB stick, you first must be booted into Privatix Live through a CD/DVD. Then you need to click the install icon on the Desktop to begin installing to a device. It is then possible to select a device for Privatix to install itself on. The installer will ask you if you would like to fill your device with blank data, this makes accessing data/recovering what was originally on the device much harder. The installer will prompt you for a user password, as well as an admin password. The installer will then start it's time consuming process of installing Privatix to the device.

To boot into Privatix from the device, you can stop the computer booting, and then boot into the external device. During booting, Privatix will prompt you for your the password set up during the installation.

==Basic Operation==

===On An External Device===

The main way of utilizing the Privatix Live-System is done by installing the system on an external device. In our case, we used an 8 GB USB stick. When the system is installed on an external device, it is easy to use the system for its intended purpose--having portable anonymous and secure system. We tested this portable version of the system on several laptops with no trouble and no noticeable discretion in use between the different machines. We attempted to use the the system for the following use cases: anonymous web browsing, secure email, data encryption and secure data transportation.

Apart from this, Privatix also came with OpenOffice applications for editing all types of data and much of the basic GNOME functionality, including (but not limited to):
* Pidgin IM and Empathy IM Client for instant messaging
* Evolution Mail for sending and retrieving email
* gedit for text editing

====Anonymous Web Browsing====
[[File:TOR.png|thumb|right|TOR is enabled by default in Privatix]]
The main thing we liked about this system was the secure and anonymous web browsing. The default browser in the system is IceWeasal (an older version of GNU IceCat--a re-branding of FireFox compatible with both Linux and Mac systems) which comes equipped with security features not available by default in FireFox. The main add on that I liked was that The Onion Router (TOR) is installed and enabled by default (it can be disabled if the user wishes). TOR is an open source project meant to provide absolute anonymity online--mainly preventing anyone from learning your location or browsing habits--by routing webpage requests through virtual tunnels made up of individual TOR nodes. Since no two "paths" for a request are ever the same there is no way for your traffic to be monitored. <ref name="TOR Project - About">[https://www.torproject.org/about/overview.html.en TOR Project - About](Last accessed 10-10-11)</ref>

====Secure Email====

The Privatix Live-System also came equipped with the security-conscious email client IceDove--an unbranded ThunderBird mail client (a cross-platform email client that provides government-grade security features). The email client was easily setup and used, supporting digital signing and message encryption via certificates by default (as with TOR, this could be disabled if the user wished). <ref name="icedove">[http://packages.debian.org/sid/icedove IceDove](Last accessed 10-10-11)</ref>

====Data Encryption====
[[File:Encrypt.jpg|thumb|right|Software to encrypt external device]]
The Privatix Live-System also has the ability to encrypt external devices (besides the external device that the system is installed on). This meant that we could have an unlimited amount of encrypted data, not being limited to the size of the external device that the system itself is installed on. The ability to encrypt secondary external devices is very handy as much of the space on the external device that Privatix is installed on is taken up by the system itself, especially if one fills the device with blank decoy data on installation. The encryption software was easily used, well designed and was able to be utilized by absolute beginners of the system.

====Secure Data Transportation====
There are two ways that Privatix fulfills its secure data transportation goal:
# When saving data on the external device with the Privatix Live-System, the data is automatically encrypted and is also password protected (since the portable version of Privatix requires a password to use it). <ref name="Privatix FAQ">[http://www.mandalka.name/privatix/index.html.en Privatix FAQ](Last accessed 10-10-11)</ref>
# As mentioned above, Privatix allows for the encryption of secondary external devices, hence meaning that data can be securely transported without even having the Privatix Live-System with you.

====General Use====

Even with the additional security features not available in other distributions, Privatix would still be a very desirable live system to use. It is portable, especially once installed on an external device, and easily used with little bloatware. The default applications such as OpenOffice for data editing, Pidgin for instant messaging, various graphics editors, video player, and CD burner/extractor ensured that they system was still perfectly functional for everyday use, even with security, not intense functionality, being the main focus.

===Live CD and Virtual Box===

We found that running Privatix using the live CD and VirtualBox was equivalent.

When booting the live CD in VirtualBox, there are certain key features of the Privatix Live-System you are missing (mainly because these features are meant for the portable version to be installed on an external device). However, just booting from the live CD still gives a lot of the functionality I would use the system for--mainly the anonymous web browsing, secure email and data encryption. The key differences were the lack of portability and the inability to save any data on the live CD or VirtualBox environment.

When using only the live CD or VirtualBox all files are deleted when the system is shut down. In addition to, any files saved to the desktop by the user will not appear. They will be hidden from view, but can be viewed by opening the terminal and navigating to the desktop and running the ls command.

The main flaw in only using the system in these mediums is that the added protection of having a user account and password to access the system are no present on the live CD or when using Privatix in a virtual machine. This is due to the fact that Privatix does not implement user accounts and password protection until it has been fully installed onto an external device. As the main goal of this distribution is privacy, it would be highly recommended that the user fully install the OS onto an external device for the added security of password protection.

==Usage Evaluation==

During our use of Privatix, we found it preformed on par for what it was described as, a secure and portable system. The tools provided to encrypt data and the secure browser with add-ons for anonymity especially supported this belief. However we also found some parts of the distribution that were a cause for concern. To begin with, there was a slight language barrier as the system was originally written in German. This was made apparent by the frequent grammar mistakes in both the existing English documentation and the operating system itself indicating that English was not the primary language for the writers of this operating system. Most of the documentation for the operating system is also in German. Those who maintain Privatix and its project website are in the process of translating all their documentation as to be available in both English and German, though currently most of the supporting documentation and FAQ are in German. This made it hard to troubleshoot anything that went wrong with the system during installation or use.

We also noticed that there was no wireless drivers on either portable versions of the OS (installed on an external device or simply using the Live CD or booting up in a virtual machine) so wireless networks could not be connected to. This causes a problem because an operating system on a USB stick should be completely portable, however this driver requires you to have a hard line to use the Internet. It was also noticed that when using Privatix in VirtualBox that even though there was no wireless drivers in Privatix, the wireless capability was provided by the host OS (Windows).

Lastly, when we tried to install Privatix onto a USB it took several attempts. We discovered that to avoid many of the problems we encountered, it is better to use a larger (preferably at least 8GBs) external device for installation and to defer from filling the external device with blank decoy data during installation on an external device.

However once connected to the Internet, all software seems to work as it should. The more basic applications such as OpenOffice, the instant messaging and email clients, multimedia applications etc. function with no problems encountered, working much as they do in any other Linux distribution. The security tools also seem to work as they should. However since we do not know how to test the limits of its security measures we do not know for sure how secure these programs actually are. Overall, Privatix seems to be a very functional and portable distribution, allowing users access to standard applications for tasks such as editing and transporting data, sending/receiving email, instant messaging and multimedia applications with the added bonus of being completely secure and anonymous.

=Part 2=
==Software Packaging==
[[File:dpkg_out.png|thumb|right|Package listing, dpkg]]
[[File:aptitude_out.png|thumb|right|Package listing, aptitude]]
The packaging format that was used for the Privatix-Live System was DEB (based on the Debian packaging format). <ref name="privatix distrowatch">[http://distrowatch.com/table.php?distribution=privatix Privatix Distrowatch Page](Last accessed 12-11-11)</ref> The utilities used with this packaging format were dpkg and aptitude. Dpkg is used as the operating system's package management utility, with aptitude acting as the more user-friendly front end version. Aptitude made finding a list of installed packages quite easy. Aptitude allows you to see a full list of installed packages, with the packages being segregated into categories such as mail, web, shells and utils. As well as using aptitude, the command line can be used to access a list of installed packages. To do this, input the following in terminal and a list of all installed packages is generated. <ref name="dpkg man page">[http://manpages.ubuntu.com/manpages/lucid/man1/dpkg.1.html Dpkg Man Page](Last accessed 12-11-11)</ref>

$ dpkg -l

Though knowing how to do this in command line is useful, we found that using aptitude was generally better as the packages are segregated into categories which made viewing the list of installed packages more simple.

To add a package within Privatix, we found the easiest way was to use the one of the following commands provided by dpkg:

$ dpkg -i <package name>
or
$ dpkg --install <package name>

These commands function in the same way which means they will either install a package, or upgrade already installed versions of the package. <ref name="dpkg man page">[http://manpages.ubuntu.com/manpages/lucid/man1/dpkg.1.html Dpkg Man Page](Last accessed 12-11-11)</ref>

To remove a package within Privatix, we found the easist way was to use either of the following commands provided by dpkg:

$ dpkg -r <package name>
or
$ dpkg -P <package name>

When using "dpkg -r <package name>", everything related to the package ''except'' the configuration files are removed. To fully remove a package, however, we used "dpkg -P <package name>" which removes the entire package, including the configuration files. <ref name="dpkg man page">[http://manpages.ubuntu.com/manpages/lucid/man1/dpkg.1.html Dpkg Man Page](Last accessed 12-11-11)</ref>

We found that the software catalog for this distribution was quite extensive, especially since this distribution is meant to be portable. Privatix includes all the standard packages included with Debian (e.g. libc), as well as several other utilities meant to increase security and privacy while using the system such as IceDove, TOR and TORButton.

==Major Package Versions==

For this section of the report, we needed to determine how heavily modified by the distribution's author packages included within our distribution were. However, the distribution's author has stated that everything included is mainly based on Debian. <ref name="privatix documentation">[http://www.mandalka.name/privatix/doc.html Privatix Documentation (German)](Last accessed 12-11-11)</ref> The packages within Privatix have not been modified, the distribution's author has mainly brought together several security and privacy conscious utilities into one distribution for portable and daily use. As such, many of the packages that come with the standard install of Privatix have been included since they are included with the standard install of Debian at the time this distribution was made. Please also note that this reference was taken from the main page of the distribution but that, to view it, you will need to translate it (we used Google translate) as much of the documentation for this distribution is in German.

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th width="10%">
<p align="left">Category</p>
</th>
<th width="15%">
<p align="left">Package</p>
</th>
<th width="10%">
<p align="left">Version</p>
</th>
<th width="15%">
<p align="left">Upstream Source</p>
</th>
<th width="20%">
<p align="left">Vintage</p>
</th>
<th width="30%">
<p align="left">Package Details</p>
</th>
</tr>
<tr>
<td rowspan="3">Kernel</td>
<td>linux-base</td>
<td>2.6.32-31 </td>
<td rowspan="3">None Provided</td>
<td rowspan="3">
This version of the kernel was released in December of 2009, making it just under two years old. <ref name="linux kernel">[http://kernelnewbies.org/Linux_2_6_32 Linux Kernel v2.6.32 Info Page](Last accessed 12-11-11)</ref> The newest stable version of the Linux kernel was released just yesterday (11/11/2011), this version being listed as 3.1.1. <ref name="current kernel">[http://www.kernel.org/ Current Stable Linux Kernel](Last accessed 12-11-11)</ref> This puts the version of the Linux kernel on Privatix as being two years behind the current stable version of the Linux kernel.</td>
<td rowspan="3">
We believe that these packages were included within the distribution as they are the standard packages for the Linux kernel included in the standard install of Debian at the time Privatix was released.</td>
</tr>
<tr>
<td>linux-image-2.6.32-5-686</td>
<td>2.6.32-31</td>
</tr>
<tr>
<td>linux-image-2.6-282</td>
<td>2.6.32+39</td>
</tr>

<tr>
<td rowspan="2">libc</td>
<td>libc-bin</td>
<td rowspan="2">2.11.2-10</td>
<td rowspan="2">http://www.eglibc.org</td>
<td rowspan="2">
This version of libc was released in January 2011, making it approximately 11 months old.<ref name="eglibc">[http://packages.qa.debian.org/e/eglibc.html eglibc Source Package on Debian](Last accessed 12-11-11)</ref> This version is also the current stable version of libc, as listed on Debian. <ref name="eglibc">[http://packages.qa.debian.org/e/eglibc.html eglibc Source Package on Debian](Last accessed 12-11-11)</ref> However, a newer, unstable version (version 2.13-21), is currently undergoing testing.</td>
<td rowspan="2">This package was included as it is also included in the standard install of Debian as well as that all Linux-based systems come with a version of libc.</td>
</tr>
<tr>
<td>libc6</td>
</tr>

<tr>
<td rowspan="1">Shell</td>
<td>bash</td>
<td rowspan="1">4.1-3</td>
<td rowspan="1">http://tiswww.case.edu/php/chet/bash/bashtop.html</td>
<td rowspan="1">This version of bash was released in, approximately, April 2010. <ref name="bash">[http://packages.qa.debian.org/b/bash.html bash Source Package on Debian](Last accessed 12-11-11)</ref> It is also the current stable version of bash. <ref name="bash">[http://packages.qa.debian.org/b/bash.html bash Source Package on Debian](Last accessed 12-11-11)</ref> However, last month, version 4.2 of bash was pushed into testing and became the current experimental version.<ref name="bash">[http://packages.qa.debian.org/b/bash.html bash Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">This package was included as bash is the version of command line included with the standard install of Debian.</td>
</tr>

<tr>
<td rowspan="1">Utilities</td>
<td>busybox</td>
<td rowspan="1">1:1.17.1-8</td>
<td rowspan="1">http://www.qtsoftware.com/</td>
<td rowspan="1">This version of busybox was released in, approximately, November 2010. <ref name="busybox">[http://packages.qa.debian.org/b/busybox.html busybox Source Package on Debian](Last accessed 12-11-11)</ref> It is also the current stable version of busybox as listed on Debian. <ref name="busybox">[http://packages.qa.debian.org/b/busybox.html busybox Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">This package was included as it the version of busybox included with the standard install of Debian.</td>
</tr>
<tr>

<tr>
<td rowspan="1">Software Packaging</td>
<td>dpkg</td>
<td rowspan="1">1.15.8.10</td>
<td rowspan="1">http://wiki.debian.org/Teams/Dpkg</td>
<td rowspan="1">
This version of dpkg was released in February of 2011, making it 10 months old. <ref name="dpkg changelog">[https://launchpad.net/ubuntu/+source/dpkg/1.15.8.10ubuntu1 Dpkg Changelog](Last accessed 12-11-11)</ref> The current stable version of dpkg, as listed on Debian, is version 1.15.8.11 which was released in April of 2011. <ref name="dpkg">[http://packages.qa.debian.org/d/dpkg.html Dpkg Source Package on Debian](Last accessed 12-11-11)</ref> This would put the version of dpkg included with Privatix at 3 months behind the latest stable version.</td>
<td rowspan="1">This package was included since dpkg is the package management system of Debian, the distribution that Privatix is based off of.</td>
</tr>

<tr>
<td rowspan="3">Web Browser</td>
<td>IceWeasel</td>
<td rowspan="1">3.5.16-6</td>
<td rowspan="1">None Provided</td>
<td rowspan="1">
This version of IceWeasel was released in March 2011, making it 9 months old. <ref name="iceweasel">[http://packages.qa.debian.org/i/iceweasel.html IceWeasel Source Package on Debian](Last accessed 12-11-11)</ref> The newest stable version is version 3.5.16-11 which was released in November 2011. <ref name="iceweasel">[http://packages.qa.debian.org/i/iceweasel.html IceWeasel Source Package on Debian](Last accessed 12-11-11)</ref> This would put the version of IceWeasel included with Privatix at 9 months behind the latest stable release.</td>
<td rowspan="1">
IceWeasel was included within this distribution as it is a more security conscious browser than more mainstream browsers such as Mozilla Firefox. IceWeasel, an older version of GNU IceCat (a rebranding of FireFox), comes equipped with security features not available by default in FireFox.</td>
</tr>
<tr>
<td>Tor</td>
<td>0.201029-1</td>
<td>https://www.torproject.org</td>
<td>
This version of TOR was released in January 2011, making it 11 months old. <ref name="tor changelog">[https://launchpad.net/ubuntu/+source/tor/0.2.1.29-1 TOR Changelog](Last accessed 12-11-11)</ref> The latest stable release of TOR is version 0.2.1.30-1 which was released in July 2011. <ref name="tor">[https://launchpad.net/ubuntu/+source/tor TOR on LaunchPad](Last accessed 12-11-11)</ref></td>
<td>
This package was included to help increase security, anonymity and privacy while web browsing which is one of the main goals of the Privatix distribution. For more information on TOR, see the Basic Operation section of the report, under Anonymous Web Browsing. </td>
</tr>
<tr>
<td>TOR Button (xul-ext-torbutton)</td>
<td>1.2.5-3</td>
<td>https://www.torproject.org/torbutton/</td>
<td>
This version of TOR Button was released in October 2010, making it just over a year old.<ref name="torbutton">[https://www.torproject.org/torbutton/ TORButton](Last accessed 12-11-11)</ref> The newest stable version of this program is version 1.4.4.1 which was released last month. <ref name="torbutton">[https://www.torproject.org/torbutton/ TORButton](Last accessed 12-11-11)</ref> This would put the version of TORButton included with Privatix at about a year behind the latest stable release.</td>
<td>
This package was included in order to add to the functionality of TOR. This add-on allows the user to enable and disable TOR with the push of a button, located in the corner of their browser. </td>
</tr>

<tr>
<td rowspan="1">Email</td>
<td>icedove</td>
<td rowspan="1">3.0.11-1+s</td>
<td rowspan="1">None Provided</td>
<td rowspan="1">
This version of IceDove is the current stable version as listed on Debian. <ref name="icedove debian">[http://packages.qadebian.org/i/icedove.html IceDove Source Package on Debian](Last accessed 12-11-11)</ref> However, this version was included within Privatix before it was made stable. It was released as an unstable version in December 2010 and was later released as the current stable version in October 2011. <ref name="icedove debian">[http://packages.qadebian.org/i/icedove.html IceDove Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">
This email client was included due to the fact that it is a more security-conscious email client, providing government-grade security features, than others such as the regular version of ThunderBird. For more information on this program, refer to the Basic Operation section of this report under Secure Email.</td>
</tr>

<tr>
<td rowspan="1">Other</td>
<td>pidgin</td>
<td rowspan="1">2.7.3.1+sq</td>
<td rowspan="1">http://www.pidgin.im</td>
<td rowspan="1">
This version of the Pidgin was released in October 2010, and is also the current stable version of Pidgin as listed on Debian. <ref name="pidgin">[http://packages.qa.debian.org/p/pidgin.html Pidgin Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">
This package was included as Pidgin is the default IM client included with the standard install of Debian, the system on which Privatix is based.</td>
</tr>
</table>

==Initialization==

Privatix generally follows the same initialization process as Debian. Privatix initializes by first executing first the BIOS then the boot loader code. <ref name="debian boot process">[http://wiki.debian.org/BootProcess#System_Initialization Debian Boot Process](Last accessed 12-11-11)</ref> Privatix uses the same boot loader as Debian which is System V initialization. /etc/inittab is the configuration file, with the /sbin/init program initializing the system following the description in this configuration file. <ref name="debian boot process">[http://wiki.debian.org/BootProcess#System_Initialization Debian Boot Process](Last accessed 12-11-11)</ref> inittab will set the default run level of Privatix, which is run level 2. Following this, all the scripts located in /etc/rc2.d are executed alphabetically. <ref name="debian boot process">[http://wiki.debian.org/BootProcess#System_Initialization Debian Boot Process](Last accessed 12-11-11)</ref> These scripts are:

* '''S01polipo''': polipo web cache--a small and fast caching web proxy
* '''S01rsyslog''': enhanced multi-thread syslogd which is Linux system logging utility
* '''S01sudo''': provides sudo
* '''S02cron''': starts the scheduler of the system
* '''S02dbus''': utility to send messages between processes and applications
* '''S02rsync''': opens rsync--a program that allows files to be copied to and from remote machines
* '''S02tor''': starts TOR (for more information, see above)
* '''S03avahi-daemon''': starts the zeroconf daemon which is used for configuring the network automatically
* '''S03bluetooth''': launches bluetooth
* '''S03networ-manager''': starts a daemon that automatically switches network connections to the best available connection
* '''S04openvpn''': starts openvpn service--a generic vpn service
* '''S05gdm3''': script for the GNOME display manager
* '''S06bootlogs''': the log file handling to be done during bootup--mainly things that don't need to be done particularly early in the boot process
* '''S07rc.local''': runs the /etc/rc.local file if it exists--by default this script does nothing, it is used only to exit
* '''S07rmologin''': removes the /etc/nologin file as the last step in the boot process
* '''S07stop-bootlogd''': runs the /etc/rc.local file again, if it exists--by default this script does nothing, it is used only to exit

[[File:pstree1.png|thumb|right|Process tree after start up]]
[[File:pstree_.png|thumb|right|Process tree after start up cont.]]

Following this, the system is initialized. The processes running on the newly initialized system and what initializes them are as follows:

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr>
<th width="20%"> <b>Process Name</b> </th>
<th width="60%"> <b>Description</b> </th>
<th width="20%"> <b>Initialized By</b> </th>
</tr>
<tr>
<td> NetworkManager </td>
<td> Daemon that automatically switches network connections to the best available connection </td>
<td> S03networ-manager init script </td>
</tr>

<tr>
<td> avahi-daemon </td>
<td> zeroconf daemon which is used for configuring the network automatically </td>
<td> S03avahi-daemon init script </td>
</tr>

<tr>
<td> bluetoothd </td>
<td> Enables bluetooth to be used </td>
<td> S03bluetooth init script </td>
</tr>

<tr>
<td> bonobo-activati </td>
<td> Responsible for the activation of CORBA objects, allowing the browsing of available CORBA servers on your system (running or not), and keeping track of the running servers so one can't restart an already running server, merely reuse it. <ref name="Bonobo Activation Tutorial">[http://developer.gnome.org/bonobo-activation/stable/tutorial.html#id2719173 Bonobo Activation Tutorial](Last accessed 12-18-11)</ref></td>
<td> IB </td>
</tr>

<tr>
<td> cron </td>
<td> Scheduler of Debian systems </td>
<td> S02cron init script </td>
</tr>

<tr>
<td> dbus-launch </td>
<td> Utility to send messages between processes and applications </td>
<td> S02dbus init script </td>
</tr>

<tr>
<td> gconfd-2 </td>
<td> D </td>
<td> IB </td>
</tr>

<tr>
<td> gdm3 </td>
<td rowspan="4"> GNOME display manager </td>
<td rowspan="4"> S05gdm3 init script </td>
</tr>

<tr>
<td> gnome-screensav </td>
</tr>

<tr>
<td> gnome-settings- </td>
</tr>

<tr>
<td> gnome-terminal </td>
</tr>

<tr>
<td> gvfs-afc-volume </td>
<td rowspan="7"> User-space virtual file system. In gvfs mounts are run as separate processes that which the user can talk to using D-bus. <ref name="gvfs">[http://packages.debian.org/sid/gvfs Gvfs Description](Last accessed 12-18-11)</ref></td>
<td rowspan="7"> IB </td>
</tr>

<tr>
<td> gvfs-gdu-volume </td>
</tr>

<tr>
<td> gvfs-gphoto2-vo </td>
</tr>

<tr>
<td> gvfsd </td>
</tr>

<tr>
<td> gvfsd-burn </td>
</tr>

<tr>
<td> gvfsd-metadata </td>
</tr>

<tr>
<td> gvfsd-trash </td>
</tr>

<tr>
<td> login </td>
<td> D </td>
<td> IB </td>
</tr>

<tr>
<td> mixer_applet2 </td>
<td> D </td>
<td> IB </td>
</tr>

<tr>
<td> polipo </td>
<td> polipo web cache--a small and fast caching web proxy </td>
<td> S01polipo init script </td>
</tr>

<tr>
<td> polkitd </td>
<td> Polkit is an application level toolkit to allow unprivileged and privileged processes talk to one another. <ref name="polkit">[http://live.gnome.org/Seahorse Polkit](Last accessed 12-18-11)</ref></td>
<td> IB </td>
</tr>

<tr>
<td> seahorse-applet </td>
<td> seahorse is an applet to manage encryptions. Has puguins for nautilus and gedit. <ref name="seahorse">[http://live.gnome.org/Seahorse Seahorse-Applet](Last accessed 12-18-11)</ref></td>
<td> IB </td>
</tr>

<tr>
<td> tor </td>
<td> TOR is an open source project meant to provide anonymity online--mainly preventing anyone from learning your location or browsing habits--by routing webpage requests through virtual tunnels made up of individual TOR nodes. Since no two "paths" for a request are ever the same there is no way for your traffic to be monitored. </td>
<td> S02tor init script </td>
</tr>

<tr>
<td> udisks-daemon </td>
<td> udisks-daemon is a block device interface, using D-bus. The udisks-daemon allows for querying, mounting, unmounting, and formatting of external devices such as USB drives. It also allows for the creation and modification.<ref name="udisks-daemon">[http://packages.debian.org/sid/udisks Udisks-daemon Description](Last accessed 12-18-11)</ref></td>
<td> IB </td>
</tr>

</table>

We found this information by first confirming that Privatix used the same style of initializing as Debian. Once we ascertained this, we researched the Debian boot process. Privatix followed the same steps up until the loading of the scripts, which had some scripts that differed from Debian (e.g. TOR). Following this, we researched each of the scripts run on Privatix's default boot level of 2. The scripts are listed above, in the order they execute. To find the purpose of each of the scripts and what programs they opened, we manually went through each of the scripts. To find the processes running on the newly initialized system, we used the command "ps tree". Once we had a list of the running processes, we researched the purpose of each process. To find how each process was initialized, we manually searched through the initialization scripts and matched each process with their initialization script.

=References=

<references />

COMP 3000 2011 Report: Privatix

2011-12-19T02:30:12Z

Gbooth: /* Initialization */

=Part 1=

==Background==

The name of our chosen distribution is the Privatix Live-System. The target audience for this system are people that are concerned about privacy, anonymity and security when web-surfing, transporting/editing sensitive data, sending email etc. Therefore, the goals of this distribution are mainly security and privacy related which means being able to provide security-conscious tools and applications integrated into a portable Operating System (OS) for anyone to use at any time. The distribution is meant to be portable, coming in the form of a live Compact Diak (CD) which can be installed on an external device or a Universal Serial Bus (USB) flash drive with an encrypted password to ensure that all your data remains private, even if your external device is lost or compromised. It should be noted that the live CD is only meant for installing the OS onto a USB in order to provide a portable, privacy conscious OS. The user should not solely rely on the live CD as the OS does not yet implement password protection. This is due to the fact that there are no user accounts on the live CD, user accounts are only implemented once the full OS is installed on a USB. The Privatix Live-System incorporates many security-conscious tools for safe editing, carrying sensitive data, encrypted communication and anonymous web surfing such as built in software to encrypt external devices, IceWeasel and TOR. <ref name="privatix home">[http://www.mandalka.name/privatix/index.html.en Privatix home page](Last accessed 10-10-11)</ref>

This Privatix Live-System was developed in Germany by Markus Mandalka. It may be obtained by going to Markus Mandalka's website and navigating to the download page ([http://www.mandalka.name/privatix/download.html.en Mandalka]), selecting the version you wish to download (we chose the English version) and downloading it. The approximate size of the Privatix Live-System is 838 Megabytes (MB) for the full English version (there are smaller versions available which have had features such as GNOME removed).<ref name="Privatix download page">[http://www.mandalka.name/privatix/download.html.en Privatix download page](Last accessed 10-10-11)</ref>. The Privatix Live-System was based off of Debian ([http://distrowatch.com/table.php?distribution=debian Debian]).

==Installation/Startup==
[[File:PrivatixBoot.png|thumb|right|Privatix boot screen]]
[[File:PrivatixDesktop.png|thumb|right|Privatix desktop]]
Currently we have Privatix installed on an 8 Gigabyte (GB) USB stick in order to utilize the full power of the OS. However, Privatix can be used in a few ways other than installing it on an external device such as on a live CD/Digital Video Disk (DVD), or in a virtualized environment such as VirtualBox. It should be noted, however, that the full potential of the OS is only unlocked once the OS has been installed on an external device as it was meant to be. One main flaw in using either a virtual environment or the live CD is that user accounts, and hence password protection, are not implemented until the OS has been installed on an external device.

To install the Privatix-Live System, the user must first download the .iso from the download page ([http://www.mandalka.name/privatix/download.html.en Mandalka]). Once the .iso file is downloaded, it is possible to either burn the operating system to a CD/DVD, use VirtualBox, or install it to a USB stick.

===CD/DVD===
To install and boot Privatix with a CD/DVD, simply burn the operating system to a disk and boot from the CD/DVD created when prompted to in the BIOS. While using the Live CD, the user will have access to almost all features of the operating system. However, because no profiles were setup, if the user locks the computer, there will be no way to unlock it as no password was not setup. Note that the main purpose of the live CD/DVD is to install the OS on an external device.

===VirtualBox===
Using VirtualBox requires simply having VirtualBox installed, and when prompted for the installation media to select the .iso file downloaded for Privatix.

When the system starts up select the Live option. This brings up the main Desktop, while using VirtualBox the user will have access to all features available when using Privatix with the Live CD. However there is one small extra level of security, this is provided by the host operating system. this extra layer of security takes the form of the profile system of the host operating system.

===USB===
To install Privatix onto a USB stick, you first must be booted into Privatix Live through a CD/DVD. Then you need to click the install icon on the Desktop to begin installing to a device. It is then possible to select a device for Privatix to install itself on. The installer will ask you if you would like to fill your device with blank data, this makes accessing data/recovering what was originally on the device much harder. The installer will prompt you for a user password, as well as an admin password. The installer will then start it's time consuming process of installing Privatix to the device.

To boot into Privatix from the device, you can stop the computer booting, and then boot into the external device. During booting, Privatix will prompt you for your the password set up during the installation.

==Basic Operation==

===On An External Device===

The main way of utilizing the Privatix Live-System is done by installing the system on an external device. In our case, we used an 8 GB USB stick. When the system is installed on an external device, it is easy to use the system for its intended purpose--having portable anonymous and secure system. We tested this portable version of the system on several laptops with no trouble and no noticeable discretion in use between the different machines. We attempted to use the the system for the following use cases: anonymous web browsing, secure email, data encryption and secure data transportation.

Apart from this, Privatix also came with OpenOffice applications for editing all types of data and much of the basic GNOME functionality, including (but not limited to):
* Pidgin IM and Empathy IM Client for instant messaging
* Evolution Mail for sending and retrieving email
* gedit for text editing

====Anonymous Web Browsing====
[[File:TOR.png|thumb|right|TOR is enabled by default in Privatix]]
The main thing we liked about this system was the secure and anonymous web browsing. The default browser in the system is IceWeasal (an older version of GNU IceCat--a re-branding of FireFox compatible with both Linux and Mac systems) which comes equipped with security features not available by default in FireFox. The main add on that I liked was that The Onion Router (TOR) is installed and enabled by default (it can be disabled if the user wishes). TOR is an open source project meant to provide absolute anonymity online--mainly preventing anyone from learning your location or browsing habits--by routing webpage requests through virtual tunnels made up of individual TOR nodes. Since no two "paths" for a request are ever the same there is no way for your traffic to be monitored. <ref name="TOR Project - About">[https://www.torproject.org/about/overview.html.en TOR Project - About](Last accessed 10-10-11)</ref>

====Secure Email====

The Privatix Live-System also came equipped with the security-conscious email client IceDove--an unbranded ThunderBird mail client (a cross-platform email client that provides government-grade security features). The email client was easily setup and used, supporting digital signing and message encryption via certificates by default (as with TOR, this could be disabled if the user wished). <ref name="icedove">[http://packages.debian.org/sid/icedove IceDove](Last accessed 10-10-11)</ref>

====Data Encryption====
[[File:Encrypt.jpg|thumb|right|Software to encrypt external device]]
The Privatix Live-System also has the ability to encrypt external devices (besides the external device that the system is installed on). This meant that we could have an unlimited amount of encrypted data, not being limited to the size of the external device that the system itself is installed on. The ability to encrypt secondary external devices is very handy as much of the space on the external device that Privatix is installed on is taken up by the system itself, especially if one fills the device with blank decoy data on installation. The encryption software was easily used, well designed and was able to be utilized by absolute beginners of the system.

====Secure Data Transportation====
There are two ways that Privatix fulfills its secure data transportation goal:
# When saving data on the external device with the Privatix Live-System, the data is automatically encrypted and is also password protected (since the portable version of Privatix requires a password to use it). <ref name="Privatix FAQ">[http://www.mandalka.name/privatix/index.html.en Privatix FAQ](Last accessed 10-10-11)</ref>
# As mentioned above, Privatix allows for the encryption of secondary external devices, hence meaning that data can be securely transported without even having the Privatix Live-System with you.

====General Use====

Even with the additional security features not available in other distributions, Privatix would still be a very desirable live system to use. It is portable, especially once installed on an external device, and easily used with little bloatware. The default applications such as OpenOffice for data editing, Pidgin for instant messaging, various graphics editors, video player, and CD burner/extractor ensured that they system was still perfectly functional for everyday use, even with security, not intense functionality, being the main focus.

===Live CD and Virtual Box===

We found that running Privatix using the live CD and VirtualBox was equivalent.

When booting the live CD in VirtualBox, there are certain key features of the Privatix Live-System you are missing (mainly because these features are meant for the portable version to be installed on an external device). However, just booting from the live CD still gives a lot of the functionality I would use the system for--mainly the anonymous web browsing, secure email and data encryption. The key differences were the lack of portability and the inability to save any data on the live CD or VirtualBox environment.

When using only the live CD or VirtualBox all files are deleted when the system is shut down. In addition to, any files saved to the desktop by the user will not appear. They will be hidden from view, but can be viewed by opening the terminal and navigating to the desktop and running the ls command.

The main flaw in only using the system in these mediums is that the added protection of having a user account and password to access the system are no present on the live CD or when using Privatix in a virtual machine. This is due to the fact that Privatix does not implement user accounts and password protection until it has been fully installed onto an external device. As the main goal of this distribution is privacy, it would be highly recommended that the user fully install the OS onto an external device for the added security of password protection.

==Usage Evaluation==

During our use of Privatix, we found it preformed on par for what it was described as, a secure and portable system. The tools provided to encrypt data and the secure browser with add-ons for anonymity especially supported this belief. However we also found some parts of the distribution that were a cause for concern. To begin with, there was a slight language barrier as the system was originally written in German. This was made apparent by the frequent grammar mistakes in both the existing English documentation and the operating system itself indicating that English was not the primary language for the writers of this operating system. Most of the documentation for the operating system is also in German. Those who maintain Privatix and its project website are in the process of translating all their documentation as to be available in both English and German, though currently most of the supporting documentation and FAQ are in German. This made it hard to troubleshoot anything that went wrong with the system during installation or use.

We also noticed that there was no wireless drivers on either portable versions of the OS (installed on an external device or simply using the Live CD or booting up in a virtual machine) so wireless networks could not be connected to. This causes a problem because an operating system on a USB stick should be completely portable, however this driver requires you to have a hard line to use the Internet. It was also noticed that when using Privatix in VirtualBox that even though there was no wireless drivers in Privatix, the wireless capability was provided by the host OS (Windows).

Lastly, when we tried to install Privatix onto a USB it took several attempts. We discovered that to avoid many of the problems we encountered, it is better to use a larger (preferably at least 8GBs) external device for installation and to defer from filling the external device with blank decoy data during installation on an external device.

However once connected to the Internet, all software seems to work as it should. The more basic applications such as OpenOffice, the instant messaging and email clients, multimedia applications etc. function with no problems encountered, working much as they do in any other Linux distribution. The security tools also seem to work as they should. However since we do not know how to test the limits of its security measures we do not know for sure how secure these programs actually are. Overall, Privatix seems to be a very functional and portable distribution, allowing users access to standard applications for tasks such as editing and transporting data, sending/receiving email, instant messaging and multimedia applications with the added bonus of being completely secure and anonymous.

=Part 2=
==Software Packaging==
[[File:dpkg_out.png|thumb|right|Package listing, dpkg]]
[[File:aptitude_out.png|thumb|right|Package listing, aptitude]]
The packaging format that was used for the Privatix-Live System was DEB (based on the Debian packaging format). <ref name="privatix distrowatch">[http://distrowatch.com/table.php?distribution=privatix Privatix Distrowatch Page](Last accessed 12-11-11)</ref> The utilities used with this packaging format were dpkg and aptitude. Dpkg is used as the operating system's package management utility, with aptitude acting as the more user-friendly front end version. Aptitude made finding a list of installed packages quite easy. Aptitude allows you to see a full list of installed packages, with the packages being segregated into categories such as mail, web, shells and utils. As well as using aptitude, the command line can be used to access a list of installed packages. To do this, input the following in terminal and a list of all installed packages is generated. <ref name="dpkg man page">[http://manpages.ubuntu.com/manpages/lucid/man1/dpkg.1.html Dpkg Man Page](Last accessed 12-11-11)</ref>

$ dpkg -l

Though knowing how to do this in command line is useful, we found that using aptitude was generally better as the packages are segregated into categories which made viewing the list of installed packages more simple.

To add a package within Privatix, we found the easiest way was to use the one of the following commands provided by dpkg:

$ dpkg -i <package name>
or
$ dpkg --install <package name>

These commands function in the same way which means they will either install a package, or upgrade already installed versions of the package. <ref name="dpkg man page">[http://manpages.ubuntu.com/manpages/lucid/man1/dpkg.1.html Dpkg Man Page](Last accessed 12-11-11)</ref>

To remove a package within Privatix, we found the easist way was to use either of the following commands provided by dpkg:

$ dpkg -r <package name>
or
$ dpkg -P <package name>

When using "dpkg -r <package name>", everything related to the package ''except'' the configuration files are removed. To fully remove a package, however, we used "dpkg -P <package name>" which removes the entire package, including the configuration files. <ref name="dpkg man page">[http://manpages.ubuntu.com/manpages/lucid/man1/dpkg.1.html Dpkg Man Page](Last accessed 12-11-11)</ref>

We found that the software catalog for this distribution was quite extensive, especially since this distribution is meant to be portable. Privatix includes all the standard packages included with Debian (e.g. libc), as well as several other utilities meant to increase security and privacy while using the system such as IceDove, TOR and TORButton.

==Major Package Versions==

For this section of the report, we needed to determine how heavily modified by the distribution's author packages included within our distribution were. However, the distribution's author has stated that everything included is mainly based on Debian. <ref name="privatix documentation">[http://www.mandalka.name/privatix/doc.html Privatix Documentation (German)](Last accessed 12-11-11)</ref> The packages within Privatix have not been modified, the distribution's author has mainly brought together several security and privacy conscious utilities into one distribution for portable and daily use. As such, many of the packages that come with the standard install of Privatix have been included since they are included with the standard install of Debian at the time this distribution was made. Please also note that this reference was taken from the main page of the distribution but that, to view it, you will need to translate it (we used Google translate) as much of the documentation for this distribution is in German.

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th width="10%">
<p align="left">Category</p>
</th>
<th width="15%">
<p align="left">Package</p>
</th>
<th width="10%">
<p align="left">Version</p>
</th>
<th width="15%">
<p align="left">Upstream Source</p>
</th>
<th width="20%">
<p align="left">Vintage</p>
</th>
<th width="30%">
<p align="left">Package Details</p>
</th>
</tr>
<tr>
<td rowspan="3">Kernel</td>
<td>linux-base</td>
<td>2.6.32-31 </td>
<td rowspan="3">None Provided</td>
<td rowspan="3">
This version of the kernel was released in December of 2009, making it just under two years old. <ref name="linux kernel">[http://kernelnewbies.org/Linux_2_6_32 Linux Kernel v2.6.32 Info Page](Last accessed 12-11-11)</ref> The newest stable version of the Linux kernel was released just yesterday (11/11/2011), this version being listed as 3.1.1. <ref name="current kernel">[http://www.kernel.org/ Current Stable Linux Kernel](Last accessed 12-11-11)</ref> This puts the version of the Linux kernel on Privatix as being two years behind the current stable version of the Linux kernel.</td>
<td rowspan="3">
We believe that these packages were included within the distribution as they are the standard packages for the Linux kernel included in the standard install of Debian at the time Privatix was released.</td>
</tr>
<tr>
<td>linux-image-2.6.32-5-686</td>
<td>2.6.32-31</td>
</tr>
<tr>
<td>linux-image-2.6-282</td>
<td>2.6.32+39</td>
</tr>

<tr>
<td rowspan="2">libc</td>
<td>libc-bin</td>
<td rowspan="2">2.11.2-10</td>
<td rowspan="2">http://www.eglibc.org</td>
<td rowspan="2">
This version of libc was released in January 2011, making it approximately 11 months old.<ref name="eglibc">[http://packages.qa.debian.org/e/eglibc.html eglibc Source Package on Debian](Last accessed 12-11-11)</ref> This version is also the current stable version of libc, as listed on Debian. <ref name="eglibc">[http://packages.qa.debian.org/e/eglibc.html eglibc Source Package on Debian](Last accessed 12-11-11)</ref> However, a newer, unstable version (version 2.13-21), is currently undergoing testing.</td>
<td rowspan="2">This package was included as it is also included in the standard install of Debian as well as that all Linux-based systems come with a version of libc.</td>
</tr>
<tr>
<td>libc6</td>
</tr>

<tr>
<td rowspan="1">Shell</td>
<td>bash</td>
<td rowspan="1">4.1-3</td>
<td rowspan="1">http://tiswww.case.edu/php/chet/bash/bashtop.html</td>
<td rowspan="1">This version of bash was released in, approximately, April 2010. <ref name="bash">[http://packages.qa.debian.org/b/bash.html bash Source Package on Debian](Last accessed 12-11-11)</ref> It is also the current stable version of bash. <ref name="bash">[http://packages.qa.debian.org/b/bash.html bash Source Package on Debian](Last accessed 12-11-11)</ref> However, last month, version 4.2 of bash was pushed into testing and became the current experimental version.<ref name="bash">[http://packages.qa.debian.org/b/bash.html bash Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">This package was included as bash is the version of command line included with the standard install of Debian.</td>
</tr>

<tr>
<td rowspan="1">Utilities</td>
<td>busybox</td>
<td rowspan="1">1:1.17.1-8</td>
<td rowspan="1">http://www.qtsoftware.com/</td>
<td rowspan="1">This version of busybox was released in, approximately, November 2010. <ref name="busybox">[http://packages.qa.debian.org/b/busybox.html busybox Source Package on Debian](Last accessed 12-11-11)</ref> It is also the current stable version of busybox as listed on Debian. <ref name="busybox">[http://packages.qa.debian.org/b/busybox.html busybox Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">This package was included as it the version of busybox included with the standard install of Debian.</td>
</tr>
<tr>

<tr>
<td rowspan="1">Software Packaging</td>
<td>dpkg</td>
<td rowspan="1">1.15.8.10</td>
<td rowspan="1">http://wiki.debian.org/Teams/Dpkg</td>
<td rowspan="1">
This version of dpkg was released in February of 2011, making it 10 months old. <ref name="dpkg changelog">[https://launchpad.net/ubuntu/+source/dpkg/1.15.8.10ubuntu1 Dpkg Changelog](Last accessed 12-11-11)</ref> The current stable version of dpkg, as listed on Debian, is version 1.15.8.11 which was released in April of 2011. <ref name="dpkg">[http://packages.qa.debian.org/d/dpkg.html Dpkg Source Package on Debian](Last accessed 12-11-11)</ref> This would put the version of dpkg included with Privatix at 3 months behind the latest stable version.</td>
<td rowspan="1">This package was included since dpkg is the package management system of Debian, the distribution that Privatix is based off of.</td>
</tr>

<tr>
<td rowspan="3">Web Browser</td>
<td>IceWeasel</td>
<td rowspan="1">3.5.16-6</td>
<td rowspan="1">None Provided</td>
<td rowspan="1">
This version of IceWeasel was released in March 2011, making it 9 months old. <ref name="iceweasel">[http://packages.qa.debian.org/i/iceweasel.html IceWeasel Source Package on Debian](Last accessed 12-11-11)</ref> The newest stable version is version 3.5.16-11 which was released in November 2011. <ref name="iceweasel">[http://packages.qa.debian.org/i/iceweasel.html IceWeasel Source Package on Debian](Last accessed 12-11-11)</ref> This would put the version of IceWeasel included with Privatix at 9 months behind the latest stable release.</td>
<td rowspan="1">
IceWeasel was included within this distribution as it is a more security conscious browser than more mainstream browsers such as Mozilla Firefox. IceWeasel, an older version of GNU IceCat (a rebranding of FireFox), comes equipped with security features not available by default in FireFox.</td>
</tr>
<tr>
<td>Tor</td>
<td>0.201029-1</td>
<td>https://www.torproject.org</td>
<td>
This version of TOR was released in January 2011, making it 11 months old. <ref name="tor changelog">[https://launchpad.net/ubuntu/+source/tor/0.2.1.29-1 TOR Changelog](Last accessed 12-11-11)</ref> The latest stable release of TOR is version 0.2.1.30-1 which was released in July 2011. <ref name="tor">[https://launchpad.net/ubuntu/+source/tor TOR on LaunchPad](Last accessed 12-11-11)</ref></td>
<td>
This package was included to help increase security, anonymity and privacy while web browsing which is one of the main goals of the Privatix distribution. For more information on TOR, see the Basic Operation section of the report, under Anonymous Web Browsing. </td>
</tr>
<tr>
<td>TOR Button (xul-ext-torbutton)</td>
<td>1.2.5-3</td>
<td>https://www.torproject.org/torbutton/</td>
<td>
This version of TOR Button was released in October 2010, making it just over a year old.<ref name="torbutton">[https://www.torproject.org/torbutton/ TORButton](Last accessed 12-11-11)</ref> The newest stable version of this program is version 1.4.4.1 which was released last month. <ref name="torbutton">[https://www.torproject.org/torbutton/ TORButton](Last accessed 12-11-11)</ref> This would put the version of TORButton included with Privatix at about a year behind the latest stable release.</td>
<td>
This package was included in order to add to the functionality of TOR. This add-on allows the user to enable and disable TOR with the push of a button, located in the corner of their browser. </td>
</tr>

<tr>
<td rowspan="1">Email</td>
<td>icedove</td>
<td rowspan="1">3.0.11-1+s</td>
<td rowspan="1">None Provided</td>
<td rowspan="1">
This version of IceDove is the current stable version as listed on Debian. <ref name="icedove debian">[http://packages.qadebian.org/i/icedove.html IceDove Source Package on Debian](Last accessed 12-11-11)</ref> However, this version was included within Privatix before it was made stable. It was released as an unstable version in December 2010 and was later released as the current stable version in October 2011. <ref name="icedove debian">[http://packages.qadebian.org/i/icedove.html IceDove Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">
This email client was included due to the fact that it is a more security-conscious email client, providing government-grade security features, than others such as the regular version of ThunderBird. For more information on this program, refer to the Basic Operation section of this report under Secure Email.</td>
</tr>

<tr>
<td rowspan="1">Other</td>
<td>pidgin</td>
<td rowspan="1">2.7.3.1+sq</td>
<td rowspan="1">http://www.pidgin.im</td>
<td rowspan="1">
This version of the Pidgin was released in October 2010, and is also the current stable version of Pidgin as listed on Debian. <ref name="pidgin">[http://packages.qa.debian.org/p/pidgin.html Pidgin Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">
This package was included as Pidgin is the default IM client included with the standard install of Debian, the system on which Privatix is based.</td>
</tr>
</table>

==Initialization==

Privatix generally follows the same initialization process as Debian. Privatix initializes by first executing first the BIOS then the boot loader code. <ref name="debian boot process">[http://wiki.debian.org/BootProcess#System_Initialization Debian Boot Process](Last accessed 12-11-11)</ref> Privatix uses the same boot loader as Debian which is System V initialization. /etc/inittab is the configuration file, with the /sbin/init program initializing the system following the description in this configuration file. <ref name="debian boot process">[http://wiki.debian.org/BootProcess#System_Initialization Debian Boot Process](Last accessed 12-11-11)</ref> inittab will set the default run level of Privatix, which is run level 2. Following this, all the scripts located in /etc/rc2.d are executed alphabetically. <ref name="debian boot process">[http://wiki.debian.org/BootProcess#System_Initialization Debian Boot Process](Last accessed 12-11-11)</ref> These scripts are:

* '''S01polipo''': polipo web cache--a small and fast caching web proxy
* '''S01rsyslog''': enhanced multi-thread syslogd which is Linux system logging utility
* '''S01sudo''': provides sudo
* '''S02cron''': starts the scheduler of the system
* '''S02dbus''': utility to send messages between processes and applications
* '''S02rsync''': opens rsync--a program that allows files to be copied to and from remote machines
* '''S02tor''': starts TOR (for more information, see above)
* '''S03avahi-daemon''': starts the zeroconf daemon which is used for configuring the network automatically
* '''S03bluetooth''': launches bluetooth
* '''S03networ-manager''': starts a daemon that automatically switches network connections to the best available connection
* '''S04openvpn''': starts openvpn service--a generic vpn service
* '''S05gdm3''': script for the GNOME display manager
* '''S06bootlogs''': the log file handling to be done during bootup--mainly things that don't need to be done particularly early in the boot process
* '''S07rc.local''': runs the /etc/rc.local file if it exists--by default this script does nothing, it is used only to exit
* '''S07rmologin''': removes the /etc/nologin file as the last step in the boot process
* '''S07stop-bootlogd''': runs the /etc/rc.local file again, if it exists--by default this script does nothing, it is used only to exit

Following this, the system is initialized. The processes running on the newly initialized system and what initializes them are as follows:

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr>
<th width="20%"> <b>Process Name</b> </th>
<th width="60%"> <b>Description</b> </th>
<th width="20%"> <b>Initialized By</b> </th>
</tr>
<tr>
<td> NetworkManager </td>
<td> Daemon that automatically switches network connections to the best available connection </td>
<td> S03networ-manager init script </td>
</tr>

<tr>
<td> avahi-daemon </td>
<td> zeroconf daemon which is used for configuring the network automatically </td>
<td> S03avahi-daemon init script </td>
</tr>

<tr>
<td> bluetoothd </td>
<td> Enables bluetooth to be used </td>
<td> S03bluetooth init script </td>
</tr>

<tr>
<td> bonobo-activati </td>
<td> Responsible for the activation of CORBA objects, allowing the browsing of available CORBA servers on your system (running or not), and keeping track of the running servers so one can't restart an already running server, merely reuse it. <ref name="Bonobo Activation Tutorial">[http://developer.gnome.org/bonobo-activation/stable/tutorial.html#id2719173 Bonobo Activation Tutorial](Last accessed 18-12-11)</ref></td>
<td> IB </td>
</tr>

<tr>
<td> cron </td>
<td> Scheduler of Debian systems </td>
<td> S02cron init script </td>
</tr>

<tr>
<td> dbus-launch </td>
<td> Utility to send messages between processes and applications </td>
<td> S02dbus init script </td>
</tr>

<tr>
<td> gconfd-2 </td>
<td> D </td>
<td> IB </td>
</tr>

<tr>
<td> gdm3 </td>
<td rowspan="4"> GNOME display manager </td>
<td rowspan="4"> S05gdm3 init script </td>
</tr>

<tr>
<td> gnome-screensav </td>
</tr>

<tr>
<td> gnome-settings- </td>
</tr>

<tr>
<td> gnome-terminal </td>
</tr>

<tr>
<td> gvfs-afc-volume </td>
<td rowspan="7"> User-space virtual file system. In gvfs mounts are run as separate processes that which the user can talk to using D-bus. <ref name="gvfs">[http://packages.debian.org/sid/gvfs Gvfs Description](Last accessed 12-18-11)</ref></td>
<td rowspan="7"> IB </td>
</tr>

<tr>
<td> gvfs-gdu-volume </td>
</tr>

<tr>
<td> gvfs-gphoto2-vo </td>
</tr>

<tr>
<td> gvfsd </td>
</tr>

<tr>
<td> gvfsd-burn </td>
</tr>

<tr>
<td> gvfsd-metadata </td>
</tr>

<tr>
<td> gvfsd-trash </td>
</tr>

<tr>
<td> login </td>
<td> D </td>
<td> IB </td>
</tr>

<tr>
<td> mixer_applet2 </td>
<td> D </td>
<td> IB </td>
</tr>

<tr>
<td> polipo </td>
<td> polipo web cache--a small and fast caching web proxy </td>
<td> S01polipo init script </td>
</tr>

<tr>
<td> polkitd </td>
<td> Polkit is an application level toolkit to allow unprivileged and privileged processes talk to one another. <ref name="polkit">[http://live.gnome.org/Seahorse Polkit](Last accessed 12-18-11)</ref></td>
<td> IB </td>
</tr>

<tr>
<td> seahorse-applet </td>
<td> seahorse is an applet to manage encryptions. Has puguins for nautilus and gedit. <ref name="seahorse">[http://live.gnome.org/Seahorse Seahorse-Applet](Last accessed 12-18-11)</ref></td>
<td> IB </td>
</tr>

<tr>
<td> tor </td>
<td> TOR is an open source project meant to provide anonymity online--mainly preventing anyone from learning your location or browsing habits--by routing webpage requests through virtual tunnels made up of individual TOR nodes. Since no two "paths" for a request are ever the same there is no way for your traffic to be monitored. </td>
<td> S02tor init script </td>
</tr>

<tr>
<td> udisks-daemon </td>
<td> udisks-daemon is a block device interface, using D-bus. The udisks-daemon allows for querying, mounting, unmounting, and formatting of external devices such as USB drives. It also allows for the creation and modification.<ref name="udisks-daemon">[http://packages.debian.org/sid/udisks Udisks-daemon Description](Last accessed 12-18-11)</ref></td>
<td> IB </td>
</tr>

</table>

We found this information by first confirming that Privatix used the same style of initializing as Debian. Once we ascertained this, we researched the Debian boot process. Privatix followed the same steps up until the loading of the scripts, which had some scripts that differed from Debian (e.g. TOR). Following this, we researched each of the scripts run on Privatix's default boot level of 2. The scripts are listed above, in the order they execute. To find the purpose of each of the scripts and what programs they opened, we manually went through each of the scripts. To find the processes running on the newly initialized system, we used the command "ps tree". Once we had a list of the running processes, we researched the purpose of each process. To find how each process was initialized, we manually searched through the initialization scripts and matched each process with their initialization script.

=References=

<references />

COMP 3000 2011 Report: Privatix

2011-12-19T02:22:22Z

Gbooth: /* Initialization */

=Part 1=

==Background==

The name of our chosen distribution is the Privatix Live-System. The target audience for this system are people that are concerned about privacy, anonymity and security when web-surfing, transporting/editing sensitive data, sending email etc. Therefore, the goals of this distribution are mainly security and privacy related which means being able to provide security-conscious tools and applications integrated into a portable Operating System (OS) for anyone to use at any time. The distribution is meant to be portable, coming in the form of a live Compact Diak (CD) which can be installed on an external device or a Universal Serial Bus (USB) flash drive with an encrypted password to ensure that all your data remains private, even if your external device is lost or compromised. It should be noted that the live CD is only meant for installing the OS onto a USB in order to provide a portable, privacy conscious OS. The user should not solely rely on the live CD as the OS does not yet implement password protection. This is due to the fact that there are no user accounts on the live CD, user accounts are only implemented once the full OS is installed on a USB. The Privatix Live-System incorporates many security-conscious tools for safe editing, carrying sensitive data, encrypted communication and anonymous web surfing such as built in software to encrypt external devices, IceWeasel and TOR. <ref name="privatix home">[http://www.mandalka.name/privatix/index.html.en Privatix home page](Last accessed 10-10-11)</ref>

This Privatix Live-System was developed in Germany by Markus Mandalka. It may be obtained by going to Markus Mandalka's website and navigating to the download page ([http://www.mandalka.name/privatix/download.html.en Mandalka]), selecting the version you wish to download (we chose the English version) and downloading it. The approximate size of the Privatix Live-System is 838 Megabytes (MB) for the full English version (there are smaller versions available which have had features such as GNOME removed).<ref name="Privatix download page">[http://www.mandalka.name/privatix/download.html.en Privatix download page](Last accessed 10-10-11)</ref>. The Privatix Live-System was based off of Debian ([http://distrowatch.com/table.php?distribution=debian Debian]).

==Installation/Startup==
[[File:PrivatixBoot.png|thumb|right|Privatix boot screen]]
[[File:PrivatixDesktop.png|thumb|right|Privatix desktop]]
Currently we have Privatix installed on an 8 Gigabyte (GB) USB stick in order to utilize the full power of the OS. However, Privatix can be used in a few ways other than installing it on an external device such as on a live CD/Digital Video Disk (DVD), or in a virtualized environment such as VirtualBox. It should be noted, however, that the full potential of the OS is only unlocked once the OS has been installed on an external device as it was meant to be. One main flaw in using either a virtual environment or the live CD is that user accounts, and hence password protection, are not implemented until the OS has been installed on an external device.

To install the Privatix-Live System, the user must first download the .iso from the download page ([http://www.mandalka.name/privatix/download.html.en Mandalka]). Once the .iso file is downloaded, it is possible to either burn the operating system to a CD/DVD, use VirtualBox, or install it to a USB stick.

===CD/DVD===
To install and boot Privatix with a CD/DVD, simply burn the operating system to a disk and boot from the CD/DVD created when prompted to in the BIOS. While using the Live CD, the user will have access to almost all features of the operating system. However, because no profiles were setup, if the user locks the computer, there will be no way to unlock it as no password was not setup. Note that the main purpose of the live CD/DVD is to install the OS on an external device.

===VirtualBox===
Using VirtualBox requires simply having VirtualBox installed, and when prompted for the installation media to select the .iso file downloaded for Privatix.

When the system starts up select the Live option. This brings up the main Desktop, while using VirtualBox the user will have access to all features available when using Privatix with the Live CD. However there is one small extra level of security, this is provided by the host operating system. this extra layer of security takes the form of the profile system of the host operating system.

===USB===
To install Privatix onto a USB stick, you first must be booted into Privatix Live through a CD/DVD. Then you need to click the install icon on the Desktop to begin installing to a device. It is then possible to select a device for Privatix to install itself on. The installer will ask you if you would like to fill your device with blank data, this makes accessing data/recovering what was originally on the device much harder. The installer will prompt you for a user password, as well as an admin password. The installer will then start it's time consuming process of installing Privatix to the device.

To boot into Privatix from the device, you can stop the computer booting, and then boot into the external device. During booting, Privatix will prompt you for your the password set up during the installation.

==Basic Operation==

===On An External Device===

The main way of utilizing the Privatix Live-System is done by installing the system on an external device. In our case, we used an 8 GB USB stick. When the system is installed on an external device, it is easy to use the system for its intended purpose--having portable anonymous and secure system. We tested this portable version of the system on several laptops with no trouble and no noticeable discretion in use between the different machines. We attempted to use the the system for the following use cases: anonymous web browsing, secure email, data encryption and secure data transportation.

Apart from this, Privatix also came with OpenOffice applications for editing all types of data and much of the basic GNOME functionality, including (but not limited to):
* Pidgin IM and Empathy IM Client for instant messaging
* Evolution Mail for sending and retrieving email
* gedit for text editing

====Anonymous Web Browsing====
[[File:TOR.png|thumb|right|TOR is enabled by default in Privatix]]
The main thing we liked about this system was the secure and anonymous web browsing. The default browser in the system is IceWeasal (an older version of GNU IceCat--a re-branding of FireFox compatible with both Linux and Mac systems) which comes equipped with security features not available by default in FireFox. The main add on that I liked was that The Onion Router (TOR) is installed and enabled by default (it can be disabled if the user wishes). TOR is an open source project meant to provide absolute anonymity online--mainly preventing anyone from learning your location or browsing habits--by routing webpage requests through virtual tunnels made up of individual TOR nodes. Since no two "paths" for a request are ever the same there is no way for your traffic to be monitored. <ref name="TOR Project - About">[https://www.torproject.org/about/overview.html.en TOR Project - About](Last accessed 10-10-11)</ref>

====Secure Email====

The Privatix Live-System also came equipped with the security-conscious email client IceDove--an unbranded ThunderBird mail client (a cross-platform email client that provides government-grade security features). The email client was easily setup and used, supporting digital signing and message encryption via certificates by default (as with TOR, this could be disabled if the user wished). <ref name="icedove">[http://packages.debian.org/sid/icedove IceDove](Last accessed 10-10-11)</ref>

====Data Encryption====
[[File:Encrypt.jpg|thumb|right|Software to encrypt external device]]
The Privatix Live-System also has the ability to encrypt external devices (besides the external device that the system is installed on). This meant that we could have an unlimited amount of encrypted data, not being limited to the size of the external device that the system itself is installed on. The ability to encrypt secondary external devices is very handy as much of the space on the external device that Privatix is installed on is taken up by the system itself, especially if one fills the device with blank decoy data on installation. The encryption software was easily used, well designed and was able to be utilized by absolute beginners of the system.

====Secure Data Transportation====
There are two ways that Privatix fulfills its secure data transportation goal:
# When saving data on the external device with the Privatix Live-System, the data is automatically encrypted and is also password protected (since the portable version of Privatix requires a password to use it). <ref name="Privatix FAQ">[http://www.mandalka.name/privatix/index.html.en Privatix FAQ](Last accessed 10-10-11)</ref>
# As mentioned above, Privatix allows for the encryption of secondary external devices, hence meaning that data can be securely transported without even having the Privatix Live-System with you.

====General Use====

Even with the additional security features not available in other distributions, Privatix would still be a very desirable live system to use. It is portable, especially once installed on an external device, and easily used with little bloatware. The default applications such as OpenOffice for data editing, Pidgin for instant messaging, various graphics editors, video player, and CD burner/extractor ensured that they system was still perfectly functional for everyday use, even with security, not intense functionality, being the main focus.

===Live CD and Virtual Box===

We found that running Privatix using the live CD and VirtualBox was equivalent.

When booting the live CD in VirtualBox, there are certain key features of the Privatix Live-System you are missing (mainly because these features are meant for the portable version to be installed on an external device). However, just booting from the live CD still gives a lot of the functionality I would use the system for--mainly the anonymous web browsing, secure email and data encryption. The key differences were the lack of portability and the inability to save any data on the live CD or VirtualBox environment.

When using only the live CD or VirtualBox all files are deleted when the system is shut down. In addition to, any files saved to the desktop by the user will not appear. They will be hidden from view, but can be viewed by opening the terminal and navigating to the desktop and running the ls command.

The main flaw in only using the system in these mediums is that the added protection of having a user account and password to access the system are no present on the live CD or when using Privatix in a virtual machine. This is due to the fact that Privatix does not implement user accounts and password protection until it has been fully installed onto an external device. As the main goal of this distribution is privacy, it would be highly recommended that the user fully install the OS onto an external device for the added security of password protection.

==Usage Evaluation==

During our use of Privatix, we found it preformed on par for what it was described as, a secure and portable system. The tools provided to encrypt data and the secure browser with add-ons for anonymity especially supported this belief. However we also found some parts of the distribution that were a cause for concern. To begin with, there was a slight language barrier as the system was originally written in German. This was made apparent by the frequent grammar mistakes in both the existing English documentation and the operating system itself indicating that English was not the primary language for the writers of this operating system. Most of the documentation for the operating system is also in German. Those who maintain Privatix and its project website are in the process of translating all their documentation as to be available in both English and German, though currently most of the supporting documentation and FAQ are in German. This made it hard to troubleshoot anything that went wrong with the system during installation or use.

We also noticed that there was no wireless drivers on either portable versions of the OS (installed on an external device or simply using the Live CD or booting up in a virtual machine) so wireless networks could not be connected to. This causes a problem because an operating system on a USB stick should be completely portable, however this driver requires you to have a hard line to use the Internet. It was also noticed that when using Privatix in VirtualBox that even though there was no wireless drivers in Privatix, the wireless capability was provided by the host OS (Windows).

Lastly, when we tried to install Privatix onto a USB it took several attempts. We discovered that to avoid many of the problems we encountered, it is better to use a larger (preferably at least 8GBs) external device for installation and to defer from filling the external device with blank decoy data during installation on an external device.

However once connected to the Internet, all software seems to work as it should. The more basic applications such as OpenOffice, the instant messaging and email clients, multimedia applications etc. function with no problems encountered, working much as they do in any other Linux distribution. The security tools also seem to work as they should. However since we do not know how to test the limits of its security measures we do not know for sure how secure these programs actually are. Overall, Privatix seems to be a very functional and portable distribution, allowing users access to standard applications for tasks such as editing and transporting data, sending/receiving email, instant messaging and multimedia applications with the added bonus of being completely secure and anonymous.

=Part 2=
==Software Packaging==
[[File:dpkg_out.png|thumb|right|Package listing, dpkg]]
[[File:aptitude_out.png|thumb|right|Package listing, aptitude]]
The packaging format that was used for the Privatix-Live System was DEB (based on the Debian packaging format). <ref name="privatix distrowatch">[http://distrowatch.com/table.php?distribution=privatix Privatix Distrowatch Page](Last accessed 12-11-11)</ref> The utilities used with this packaging format were dpkg and aptitude. Dpkg is used as the operating system's package management utility, with aptitude acting as the more user-friendly front end version. Aptitude made finding a list of installed packages quite easy. Aptitude allows you to see a full list of installed packages, with the packages being segregated into categories such as mail, web, shells and utils. As well as using aptitude, the command line can be used to access a list of installed packages. To do this, input the following in terminal and a list of all installed packages is generated. <ref name="dpkg man page">[http://manpages.ubuntu.com/manpages/lucid/man1/dpkg.1.html Dpkg Man Page](Last accessed 12-11-11)</ref>

$ dpkg -l

Though knowing how to do this in command line is useful, we found that using aptitude was generally better as the packages are segregated into categories which made viewing the list of installed packages more simple.

To add a package within Privatix, we found the easiest way was to use the one of the following commands provided by dpkg:

$ dpkg -i <package name>
or
$ dpkg --install <package name>

These commands function in the same way which means they will either install a package, or upgrade already installed versions of the package. <ref name="dpkg man page">[http://manpages.ubuntu.com/manpages/lucid/man1/dpkg.1.html Dpkg Man Page](Last accessed 12-11-11)</ref>

To remove a package within Privatix, we found the easist way was to use either of the following commands provided by dpkg:

$ dpkg -r <package name>
or
$ dpkg -P <package name>

When using "dpkg -r <package name>", everything related to the package ''except'' the configuration files are removed. To fully remove a package, however, we used "dpkg -P <package name>" which removes the entire package, including the configuration files. <ref name="dpkg man page">[http://manpages.ubuntu.com/manpages/lucid/man1/dpkg.1.html Dpkg Man Page](Last accessed 12-11-11)</ref>

We found that the software catalog for this distribution was quite extensive, especially since this distribution is meant to be portable. Privatix includes all the standard packages included with Debian (e.g. libc), as well as several other utilities meant to increase security and privacy while using the system such as IceDove, TOR and TORButton.

==Major Package Versions==

For this section of the report, we needed to determine how heavily modified by the distribution's author packages included within our distribution were. However, the distribution's author has stated that everything included is mainly based on Debian. <ref name="privatix documentation">[http://www.mandalka.name/privatix/doc.html Privatix Documentation (German)](Last accessed 12-11-11)</ref> The packages within Privatix have not been modified, the distribution's author has mainly brought together several security and privacy conscious utilities into one distribution for portable and daily use. As such, many of the packages that come with the standard install of Privatix have been included since they are included with the standard install of Debian at the time this distribution was made. Please also note that this reference was taken from the main page of the distribution but that, to view it, you will need to translate it (we used Google translate) as much of the documentation for this distribution is in German.

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th width="10%">
<p align="left">Category</p>
</th>
<th width="15%">
<p align="left">Package</p>
</th>
<th width="10%">
<p align="left">Version</p>
</th>
<th width="15%">
<p align="left">Upstream Source</p>
</th>
<th width="20%">
<p align="left">Vintage</p>
</th>
<th width="30%">
<p align="left">Package Details</p>
</th>
</tr>
<tr>
<td rowspan="3">Kernel</td>
<td>linux-base</td>
<td>2.6.32-31 </td>
<td rowspan="3">None Provided</td>
<td rowspan="3">
This version of the kernel was released in December of 2009, making it just under two years old. <ref name="linux kernel">[http://kernelnewbies.org/Linux_2_6_32 Linux Kernel v2.6.32 Info Page](Last accessed 12-11-11)</ref> The newest stable version of the Linux kernel was released just yesterday (11/11/2011), this version being listed as 3.1.1. <ref name="current kernel">[http://www.kernel.org/ Current Stable Linux Kernel](Last accessed 12-11-11)</ref> This puts the version of the Linux kernel on Privatix as being two years behind the current stable version of the Linux kernel.</td>
<td rowspan="3">
We believe that these packages were included within the distribution as they are the standard packages for the Linux kernel included in the standard install of Debian at the time Privatix was released.</td>
</tr>
<tr>
<td>linux-image-2.6.32-5-686</td>
<td>2.6.32-31</td>
</tr>
<tr>
<td>linux-image-2.6-282</td>
<td>2.6.32+39</td>
</tr>

<tr>
<td rowspan="2">libc</td>
<td>libc-bin</td>
<td rowspan="2">2.11.2-10</td>
<td rowspan="2">http://www.eglibc.org</td>
<td rowspan="2">
This version of libc was released in January 2011, making it approximately 11 months old.<ref name="eglibc">[http://packages.qa.debian.org/e/eglibc.html eglibc Source Package on Debian](Last accessed 12-11-11)</ref> This version is also the current stable version of libc, as listed on Debian. <ref name="eglibc">[http://packages.qa.debian.org/e/eglibc.html eglibc Source Package on Debian](Last accessed 12-11-11)</ref> However, a newer, unstable version (version 2.13-21), is currently undergoing testing.</td>
<td rowspan="2">This package was included as it is also included in the standard install of Debian as well as that all Linux-based systems come with a version of libc.</td>
</tr>
<tr>
<td>libc6</td>
</tr>

<tr>
<td rowspan="1">Shell</td>
<td>bash</td>
<td rowspan="1">4.1-3</td>
<td rowspan="1">http://tiswww.case.edu/php/chet/bash/bashtop.html</td>
<td rowspan="1">This version of bash was released in, approximately, April 2010. <ref name="bash">[http://packages.qa.debian.org/b/bash.html bash Source Package on Debian](Last accessed 12-11-11)</ref> It is also the current stable version of bash. <ref name="bash">[http://packages.qa.debian.org/b/bash.html bash Source Package on Debian](Last accessed 12-11-11)</ref> However, last month, version 4.2 of bash was pushed into testing and became the current experimental version.<ref name="bash">[http://packages.qa.debian.org/b/bash.html bash Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">This package was included as bash is the version of command line included with the standard install of Debian.</td>
</tr>

<tr>
<td rowspan="1">Utilities</td>
<td>busybox</td>
<td rowspan="1">1:1.17.1-8</td>
<td rowspan="1">http://www.qtsoftware.com/</td>
<td rowspan="1">This version of busybox was released in, approximately, November 2010. <ref name="busybox">[http://packages.qa.debian.org/b/busybox.html busybox Source Package on Debian](Last accessed 12-11-11)</ref> It is also the current stable version of busybox as listed on Debian. <ref name="busybox">[http://packages.qa.debian.org/b/busybox.html busybox Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">This package was included as it the version of busybox included with the standard install of Debian.</td>
</tr>
<tr>

<tr>
<td rowspan="1">Software Packaging</td>
<td>dpkg</td>
<td rowspan="1">1.15.8.10</td>
<td rowspan="1">http://wiki.debian.org/Teams/Dpkg</td>
<td rowspan="1">
This version of dpkg was released in February of 2011, making it 10 months old. <ref name="dpkg changelog">[https://launchpad.net/ubuntu/+source/dpkg/1.15.8.10ubuntu1 Dpkg Changelog](Last accessed 12-11-11)</ref> The current stable version of dpkg, as listed on Debian, is version 1.15.8.11 which was released in April of 2011. <ref name="dpkg">[http://packages.qa.debian.org/d/dpkg.html Dpkg Source Package on Debian](Last accessed 12-11-11)</ref> This would put the version of dpkg included with Privatix at 3 months behind the latest stable version.</td>
<td rowspan="1">This package was included since dpkg is the package management system of Debian, the distribution that Privatix is based off of.</td>
</tr>

<tr>
<td rowspan="3">Web Browser</td>
<td>IceWeasel</td>
<td rowspan="1">3.5.16-6</td>
<td rowspan="1">None Provided</td>
<td rowspan="1">
This version of IceWeasel was released in March 2011, making it 9 months old. <ref name="iceweasel">[http://packages.qa.debian.org/i/iceweasel.html IceWeasel Source Package on Debian](Last accessed 12-11-11)</ref> The newest stable version is version 3.5.16-11 which was released in November 2011. <ref name="iceweasel">[http://packages.qa.debian.org/i/iceweasel.html IceWeasel Source Package on Debian](Last accessed 12-11-11)</ref> This would put the version of IceWeasel included with Privatix at 9 months behind the latest stable release.</td>
<td rowspan="1">
IceWeasel was included within this distribution as it is a more security conscious browser than more mainstream browsers such as Mozilla Firefox. IceWeasel, an older version of GNU IceCat (a rebranding of FireFox), comes equipped with security features not available by default in FireFox.</td>
</tr>
<tr>
<td>Tor</td>
<td>0.201029-1</td>
<td>https://www.torproject.org</td>
<td>
This version of TOR was released in January 2011, making it 11 months old. <ref name="tor changelog">[https://launchpad.net/ubuntu/+source/tor/0.2.1.29-1 TOR Changelog](Last accessed 12-11-11)</ref> The latest stable release of TOR is version 0.2.1.30-1 which was released in July 2011. <ref name="tor">[https://launchpad.net/ubuntu/+source/tor TOR on LaunchPad](Last accessed 12-11-11)</ref></td>
<td>
This package was included to help increase security, anonymity and privacy while web browsing which is one of the main goals of the Privatix distribution. For more information on TOR, see the Basic Operation section of the report, under Anonymous Web Browsing. </td>
</tr>
<tr>
<td>TOR Button (xul-ext-torbutton)</td>
<td>1.2.5-3</td>
<td>https://www.torproject.org/torbutton/</td>
<td>
This version of TOR Button was released in October 2010, making it just over a year old.<ref name="torbutton">[https://www.torproject.org/torbutton/ TORButton](Last accessed 12-11-11)</ref> The newest stable version of this program is version 1.4.4.1 which was released last month. <ref name="torbutton">[https://www.torproject.org/torbutton/ TORButton](Last accessed 12-11-11)</ref> This would put the version of TORButton included with Privatix at about a year behind the latest stable release.</td>
<td>
This package was included in order to add to the functionality of TOR. This add-on allows the user to enable and disable TOR with the push of a button, located in the corner of their browser. </td>
</tr>

<tr>
<td rowspan="1">Email</td>
<td>icedove</td>
<td rowspan="1">3.0.11-1+s</td>
<td rowspan="1">None Provided</td>
<td rowspan="1">
This version of IceDove is the current stable version as listed on Debian. <ref name="icedove debian">[http://packages.qadebian.org/i/icedove.html IceDove Source Package on Debian](Last accessed 12-11-11)</ref> However, this version was included within Privatix before it was made stable. It was released as an unstable version in December 2010 and was later released as the current stable version in October 2011. <ref name="icedove debian">[http://packages.qadebian.org/i/icedove.html IceDove Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">
This email client was included due to the fact that it is a more security-conscious email client, providing government-grade security features, than others such as the regular version of ThunderBird. For more information on this program, refer to the Basic Operation section of this report under Secure Email.</td>
</tr>

<tr>
<td rowspan="1">Other</td>
<td>pidgin</td>
<td rowspan="1">2.7.3.1+sq</td>
<td rowspan="1">http://www.pidgin.im</td>
<td rowspan="1">
This version of the Pidgin was released in October 2010, and is also the current stable version of Pidgin as listed on Debian. <ref name="pidgin">[http://packages.qa.debian.org/p/pidgin.html Pidgin Source Package on Debian](Last accessed 12-11-11)</ref></td>
<td rowspan="1">
This package was included as Pidgin is the default IM client included with the standard install of Debian, the system on which Privatix is based.</td>
</tr>
</table>

==Initialization==

Privatix generally follows the same initialization process as Debian. Privatix initializes by first executing first the BIOS then the boot loader code. <ref name="debian boot process">[http://wiki.debian.org/BootProcess#System_Initialization Debian Boot Process](Last accessed 12-11-11)</ref> Privatix uses the same boot loader as Debian which is System V initialization. /etc/inittab is the configuration file, with the /sbin/init program initializing the system following the description in this configuration file. <ref name="debian boot process">[http://wiki.debian.org/BootProcess#System_Initialization Debian Boot Process](Last accessed 12-11-11)</ref> inittab will set the default run level of Privatix, which is run level 2. Following this, all the scripts located in /etc/rc2.d are executed alphabetically. <ref name="debian boot process">[http://wiki.debian.org/BootProcess#System_Initialization Debian Boot Process](Last accessed 12-11-11)</ref> These scripts are:

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr>
<th width="20%"> <b>Process Name</b> </th>
<th width="60%"> <b>Description</b> </th>
<th width="20%"> <b>Initialized By</b> </th>
</tr>
<tr>
<td> NetworkManager </td>
<td> Daemon that automatically switches network connections to the best available connection </td>
<td> S03networ-manager init script </td>
</tr>

<tr>
<td> avahi-daemon </td>
<td> zeroconf daemon which is used for configuring the network automatically </td>
<td> S03avahi-daemon init script </td>
</tr>

<tr>
<td> bluetoothd </td>
<td> Enables bluetooth to be used </td>
<td> S03bluetooth init script </td>
</tr>

<tr>
<td> bonobo-activati </td>
<td> Responsible for the activation of CORBA objects, allowing the browsing of available CORBA servers on your system (running or not), and keeping track of the running servers so one can't restart an already running server, merely reuse it. <ref name="Bonobo Activation Tutorial">[http://developer.gnome.org/bonobo-activation/stable/tutorial.html#id2719173 Bonobo Activation Tutorial](Last accessed 18-12-11)</ref></td>
<td> IB </td>
</tr>

<tr>
<td> cron </td>
<td> Scheduler of Debian systems </td>
<td> S02cron init script </td>
</tr>

<tr>
<td> dbus-launch </td>
<td> Utility to send messages between processes and applications </td>
<td> S02dbus init script </td>
</tr>

<tr>
<td> gconfd-2 </td>
<td> D </td>
<td> IB </td>
</tr>

<tr>
<td> gdm3 </td>
<td rowspan="4"> GNOME display manager </td>
<td rowspan="4"> S05gdm3 init script </td>
</tr>

<tr>
<td> gnome-screensav </td>
</tr>

<tr>
<td> gnome-settings- </td>
</tr>

<tr>
<td> gnome-terminal </td>
</tr>

<tr>
<td> gvfs-afc-volume </td>
<td rowspan="7"> D </td>
<td rowspan="7"> IB </td>
</tr>

<tr>
<td> gvfs-gdu-volume </td>
</tr>

<tr>
<td> gvfs-gphoto2-vo </td>
</tr>

<tr>
<td> gvfsd </td>
</tr>

<tr>
<td> gvfsd-burn </td>
</tr>

<tr>
<td> gvfsd-metadata </td>
</tr>

<tr>
<td> gvfsd-trash </td>
</tr>

<tr>
<td> login </td>
<td> D </td>
<td> IB </td>
</tr>

<tr>
<td> mixer_appler2 </td>
<td> D </td>
<td> IB </td>
</tr>

<tr>
<td> polipo </td>
<td> polipo web cache--a small and fast caching web proxy </td>
<td> S01polipo init script </td>
</tr>

<tr>
<td> polkitd </td>
<td> D </td>
<td> IB </td>
</tr>

<tr>
<td> seahorse-applet </td>
<td> D </td>
<td> IB </td>
</tr>

<tr>
<td> tor </td>
<td> TOR is an open source project meant to provide anonymity online--mainly preventing anyone from learning your location or browsing habits--by routing webpage requests through virtual tunnels made up of individual TOR nodes. Since no two "paths" for a request are ever the same there is no way for your traffic to be monitored. </td>
<td> S02tor init script </td>
</tr>

<tr>
<td> udisks-daemon </td>
<td> udisks-daemon is a block device interface, using D-bus. The udisks-daemon allows for querying, mounting, unmounting, and formatting of external devices such as USB drives. It also allows for the creation and modification.<ref name="udisks-daemon">[http://packages.debian.org/sid/udisks Udisks-daemon Description](Last accessed 12-18-11)</ref></td>
<td> IB </td>
</tr>

</table>
* '''S01polipo''': polipo web cache--a small and fast caching web proxy
* '''S01rsyslog''': enhanced multi-thread syslogd which is Linux system logging utility
* '''S01sudo''': provides sudo
* '''S02cron''': starts the scheduler of the system
* '''S02dbus''': utility to send messages between processes and applications
* '''S02rsync''': opens rsync--a program that allows files to be copied to and from remote machines
* '''S02tor''': starts TOR (for more information, see above)
* '''S03avahi-daemon''': starts the zeroconf daemon which is used for configuring the network automatically
* '''S03bluetooth''': launches bluetooth
* '''S03networ-manager''': starts a daemon that automatically switches network connections to the best available connection
* '''S04openvpn''': starts openvpn service--a generic vpn service
* '''S05gdm3''': script for the GNOME display manager
* '''S06bootlogs''': the log file handling to be done during bootup--mainly things that don't need to be done particularly early in the boot process
* '''S07rc.local''': runs the /etc/rc.local file if it exists--by default this script does nothing, it is used only to exit
* '''S07rmologin''': removes the /etc/nologin file as the last step in the boot process
* '''S07stop-bootlogd''': runs the /etc/rc.local file again, if it exists--by default this script does nothing, it is used only to exit

Following this, the system is initialized.

We found this information by first confirming that Privatix used the same style of initializing as Debian. Once we ascertained this, we researched the Debian boot process. Privatix followed the same steps up until the loading of the scripts, which had some scripts that differed from Debian (e.g. TOR). Following this, we researched each of the scripts run on Privatix's default boot level of 2. The scripts are listed above, in the order they execute. To find the purpose of each of the scripts and what programs they opened, we manually went through each of the scripts.

=References=

<references />

COMP 3000 2011 Week 11 Notes

2011-12-15T18:35:10Z

Gbooth: Created page with "==Networking== It should be noted that, if networking were taken away, there would be no need for modern operating systems. Modern operating system architecture is very good for…"

==Networking==

It should be noted that, if networking were taken away, there would be no need for modern operating systems. Modern operating system architecture is very good for networking--the kernel handles receiving messages, processing the message and sending it to the appropriate procedure. The kernel will receive an interrupt from the network card, notifying it that it has a message to process and send.

'''Networking''': communication between point A and point B

'''Packet''': fixed size chunk of data (normally 1500 bytes). If one wants to send a package larger than the fixed size, the larger packet is fragmented into smaller ones. Packets can be repeatedly "wrapped" (e.g. data is wrapped in an IP packet, which is wrapped in an ethernet packet, which is wrapped in a DSL packet etc. and, once the destination is reached, all of this is stripped).

'''TCP/IP''': one way to format a packet (the "to" and "from" fields associated with the packet are numbers--IP addresses--while the contents of the "message" is the data to be sent)

'''Routers''': copies packets and relays them from router to router until the destination is reached. However, along the way, a packet may be damaged/dropped. This system of sending packets is a "best effort" practice.

'''TCP''': notion of retransmission when something is lost, reordering of packets; will interpret packet loss as congestion and will slow down

'''Sockets''': file like abstraction of the operating system

'''Ports''': ID for operating system to distinguish which process gets the data

'''Streaming Protocols''': just wants datagrams, continuous stream, usually for things like media. If packets are lost, just move on. This means that data can be lost, but everything is still alright, there is only a degradation in quality (i.e. the entire thing doesn't stop working).

'''Firewall''': filters network traffic, often by blocking ports. A standard firewall works on TCP or IP levels.

'''DPI''': deep packet inspection means that the data of the packet is what is being looked at, not the "wrappers" around the data

Time line of how data is sent to processes:

'''Data''' -> '''Ethernet Card''' (via ethernet card MAC address) -> '''Driver''' (interrupt associated with ethernet card) -> data is processed and given to the right process -> '''network stack''' (makes available to right process; puts the data in the right buffer) -> data now available to process

Note that the driver, processing the data, and network stack steps of this process are all fulfilled by the kernel.

COMP 3000 2011 Week 10 Notes

2011-12-15T18:11:37Z

Gbooth: Created page with "==Virtual Memory== '''Virtual Memory''': memory management technique; made of 32 bits divided into a 20 bit frame number and 12 bit offset that maps perfectly to a physical offs…"

==Virtual Memory==

'''Virtual Memory''': memory management technique; made of 32 bits divided into a 20 bit frame number and 12 bit offset that maps perfectly to a physical offset

'''32 bit address''': first 20 bits of the address is the frame number with the lower 12 bits specifying the offset within that frame

'''Physical Memory''': divided into frames where each frame is 4K--note that each page is also 4K meaning that any page can fit in any frame (solves fragmentation problem)

'''TLB''': mapping virtual addresses to corresponding physical ones--this is done by mapping the 20 bit frame numbers, located in the first 20 bits of a 32 bit address, to each other.

'''Page Table''': all virtual -> physical mappings are stored in the page table; when constructing a page table, a broad flat tree is desired (a good out degree for this is 1024). Page tables make use of the 4K structure of the system by having 1024 page table entries of 32 bits, which will make 4K bits.

'''PTE''': page table entries, made of 32 bits in most archives.

===Managing Memory===

'''LRU''': least recently used--the least recently used page will get kicked out of memory

'''Disk Cache''': cache of files on disk--the problem is figuring out what memory to evict first. The memory you can usually evict first is:

# Memory that is already written to disk
# Files and program binaries as they are already synced to disk

Other memory that is safe to evict is memory that has both the dirty bit and the accessed bit flipped to 0.

* '''Dirty Bit''': if what is in memory is only a copy, meaning that, if the page is kicked out of memory, there is no memory loss, the dirty bit is flipped to 0
* '''Accessed Bit''': has the memory this bit pertains to been accessed or not? A clock algorithm runs routinely and sets the access bit of all memory to zero. Next time the algorithm goes through,if you see a 1 somewhere, the memory has been accessed since the last sweep, meaning we should keep it. However, if somewhere still has a 0, it means that the memory has not been accessed since the last sweep

COMP 3000 2011 Report: Privatix

2011-12-04T15:19:38Z

Gbooth: /* Major Package Versions */

=Part 1=

==Background==

The name of our chosen distribution is the Privatix Live-System. The target audience for this system are people that are concerned about privacy, anonymity and security when web-surfing, transporting/editing sensitive data, sending email etc. Therefore, the goals of this distribution are mainly security and privacy related which means being able to provide security-conscious tools and applications integrated into a portable Operating System (OS) for anyone to use at any time. The distribution is meant to be portable, coming in the form of a live Compact Diak (CD) which can be installed on an external device or a Universal Serial Bus (USB) flash drive with an encrypted password to ensure that all your data remains private, even if your external device is lost or compromised. It should be noted that the live CD is only meant for installing the OS onto a USB in order to provide a portable, privacy conscious OS. The user should not solely rely on the live CD as the OS does not yet implement password protection. This is due to the fact that there are no user accounts on the live CD, user accounts are only implemented once the full OS is installed on a USB. The Privatix Live-System incorporates many security-conscious tools for safe editing, carrying sensitive data, encrypted communication and anonymous web surfing such as built in software to encrypt external devices, IceWeasel and TOR. <ref name="privatix home">[http://www.mandalka.name/privatix/index.html.en Privatix home page](Last accessed 10-10-11)</ref>

This Privatix Live-System was developed in Germany by Markus Mandalka. It may be obtained by going to Markus Mandalka's website and navigating to the download page ([http://www.mandalka.name/privatix/download.html.en Mandalka]), selecting the version you wish to download (we chose the English version) and downloading it. The approximate size of the Privatix Live-System is 838 Megabytes (MB) for the full English version (there are smaller versions available which have had features such as GNOME removed).<ref name="Privatix download page">[http://www.mandalka.name/privatix/download.html.en Privatix download page](Last accessed 10-10-11)</ref>. The Privatix Live-System was based off of Debian ([http://distrowatch.com/table.php?distribution=debian Debian]).

==Installation/Startup==
[[File:PrivatixBoot.png|thumb|right|Privatix boot screen]]
[[File:PrivatixDesktop.png|thumb|right|Privatix desktop]]
Currently we have Privatix installed on an 8 Gigabyte (GB) USB stick in order to utilize the full power of the OS. However, Privatix can be used in a few ways other than installing it on an external device such as on a live CD/Digital Video Disk (DVD), or in a virtualized environment such as VirtualBox. It should be noted, however, that the full potential of the OS is only unlocked once the OS has been installed on an external device as it was meant to be. One main flaw in using either a virtual environment or the live CD is that user accounts, and hence password protection, are not implemented until the OS has been installed on an external device.

To install the Privatix-Live System, the user must first download the .iso from the download page ([http://www.mandalka.name/privatix/download.html.en Mandalka]). Once the .iso file is downloaded, it is possible to either burn the operating system to a CD/DVD, use VirtualBox, or install it to a USB stick.

===CD/DVD===
To install and boot Privatix with a CD/DVD, simply burn the operating system to a disk and boot from the CD/DVD created when prompted to in the BIOS. While using the Live CD, the user will have access to almost all features of the operating system. However, because no profiles were setup, if the user locks the computer, there will be no way to unlock it as no password was not setup. Note that the main purpose of the live CD/DVD is to install the OS on an external device.

===VirtualBox===
Using VirtualBox requires simply having VirtualBox installed, and when prompted for the installation media to select the .iso file downloaded for Privatix.

When the system starts up select the Live option. This brings up the main Desktop, while using VirtualBox the user will have access to all features available when using Privatix with the Live CD. However there is one small extra level of security, this is provided by the host operating system. this extra layer of security takes the form of the profile system of the host operating system.

===USB===
To install Privatix onto a USB stick, you first must be booted into Privatix Live through a CD/DVD. Then you need to click the install icon on the Desktop to begin installing to a device. It is then possible to select a device for Privatix to install itself on. The installer will ask you if you would like to fill your device with blank data, this makes accessing data/recovering what was originally on the device much harder. The installer will prompt you for a user password, as well as an admin password. The installer will then start it's time consuming process of installing Privatix to the device.

To boot into Privatix from the device, you can stop the computer booting, and then boot into the external device. During booting, Privatix will prompt you for your the password set up during the installation.

==Basic Operation==

===On An External Device===

The main way of utilizing the Privatix Live-System is done by installing the system on an external device. In our case, we used an 8 GB USB stick. When the system is installed on an external device, it is easy to use the system for its intended purpose--having portable anonymous and secure system. We tested this portable version of the system on several laptops with no trouble and no noticeable discretion in use between the different machines. We attempted to use the the system for the following use cases: anonymous web browsing, secure email, data encryption and secure data transportation.

Apart from this, Privatix also came with OpenOffice applications for editing all types of data and much of the basic GNOME functionality, including (but not limited to):
* Pidgin IM and Empathy IM Client for instant messaging
* Evolution Mail for sending and retrieving email
* gedit for text editing

====Anonymous Web Browsing====
[[File:TOR.png|thumb|right|TOR is enabled by default in Privatix]]
The main thing we liked about this system was the secure and anonymous web browsing. The default browser in the system is IceWeasal (an older version of GNU IceCat--a re-branding of FireFox compatible with both Linux and Mac systems) which comes equipped with security features not available by default in FireFox. The main add on that I liked was that The Onion Router (TOR) is installed and enabled by default (it can be disabled if the user wishes). TOR is an open source project meant to provide absolute anonymity online--mainly preventing anyone from learning your location or browsing habits--by routing webpage requests through virtual tunnels made up of individual TOR nodes. Since no two "paths" for a request are ever the same there is no way for your traffic to be monitored. <ref name="TOR Project - About">[https://www.torproject.org/about/overview.html.en TOR Project - About](Last accessed 10-10-11)</ref>

====Secure Email====

The Privatix Live-System also came equipped with the security-conscious email client IceDove--an unbranded ThunderBird mail client (a cross-platform email client that provides government-grade security features). The email client was easily setup and used, supporting digital signing and message encryption via certificates by default (as with TOR, this could be disabled if the user wished). <ref name="icedove">[http://packages.debian.org/sid/icedove IceDove](Last accessed 10-10-11)</ref>

====Data Encryption====
[[File:Encrypt.jpg|thumb|right|Software to encrypt external device]]
The Privatix Live-System also has the ability to encrypt external devices (besides the external device that the system is installed on). This meant that we could have an unlimited amount of encrypted data, not being limited to the size of the external device that the system itself is installed on. The ability to encrypt secondary external devices is very handy as much of the space on the external device that Privatix is installed on is taken up by the system itself, especially if one fills the device with blank decoy data on installation. The encryption software was easily used, well designed and was able to be utilized by absolute beginners of the system.

====Secure Data Transportation====
There are two ways that Privatix fulfills its secure data transportation goal:
# When saving data on the external device with the Privatix Live-System, the data is automatically encrypted and is also password protected (since the portable version of Privatix requires a password to use it). <ref name="Privatix FAQ">[http://www.mandalka.name/privatix/index.html.en Privatix FAQ](Last accessed 10-10-11)</ref>
# As mentioned above, Privatix allows for the encryption of secondary external devices, hence meaning that data can be securely transported without even having the Privatix Live-System with you.

====General Use====

Even with the additional security features not available in other distributions, Privatix would still be a very desirable live system to use. It is portable, especially once installed on an external device, and easily used with little bloatware. The default applications such as OpenOffice for data editing, Pidgin for instant messaging, various graphics editors, video player, and CD burner/extractor ensured that they system was still perfectly functional for everyday use, even with security, not intense functionality, being the main focus.

===Live CD and Virtual Box===

We found that running Privatix using the live CD and VirtualBox was equivalent.

When booting the live CD in VirtualBox, there are certain key features of the Privatix Live-System you are missing (mainly because these features are meant for the portable version to be installed on an external device). However, just booting from the live CD still gives a lot of the functionality I would use the system for--mainly the anonymous web browsing, secure email and data encryption. The key differences were the lack of portability and the inability to save any data on the live CD or VirtualBox environment.

When using only the live CD or VirtualBox all files are deleted when the system is shut down. In addition to, any files saved to the desktop by the user will not appear. They will be hidden from view, but can be viewed by opening the terminal and navigating to the desktop and running the ls command.

The main flaw in only using the system in these mediums is that the added protection of having a user account and password to access the system are no present on the live CD or when using Privatix in a virtual machine. This is due to the fact that Privatix does not implement user accounts and password protection until it has been fully installed onto an external device. As the main goal of this distribution is privacy, it would be highly recommended that the user fully install the OS onto an external device for the added security of password protection.

==Usage Evaluation==

During our use of Privatix, we found it preformed on par for what it was described as, a secure and portable system. The tools provided to encrypt data and the secure browser with add-ons for anonymity especially supported this belief. However we also found some parts of the distribution that were a cause for concern. To begin with, there was a slight language barrier as the system was originally written in German. This was made apparent by the frequent grammar mistakes in both the existing English documentation and the operating system itself indicating that English was not the primary language for the writers of this operating system. Most of the documentation for the operating system is also in German. Those who maintain Privatix and its project website are in the process of translating all their documentation as to be available in both English and German, though currently most of the supporting documentation and FAQ are in German. This made it hard to troubleshoot anything that went wrong with the system during installation or use.

We also noticed that there was no wireless drivers on either portable versions of the OS (installed on an external device or simply using the Live CD or booting up in a virtual machine) so wireless networks could not be connected to. This causes a problem because an operating system on a USB stick should be completely portable, however this driver requires you to have a hard line to use the Internet. It was also noticed that when using Privatix in VirtualBox that even though there was no wireless drivers in Privatix, the wireless capability was provided by the host OS (Windows).

Lastly, when we tried to install Privatix onto a USB it took several attempts. We discovered that to avoid many of the problems we encountered, it is better to use a larger (preferably at least 8GBs) external device for installation and to defer from filling the external device with blank decoy data during installation on an external device.

However once connected to the Internet, all software seems to work as it should. The more basic applications such as OpenOffice, the instant messaging and email clients, multimedia applications etc. function with no problems encountered, working much as they do in any other Linux distribution. The security tools also seem to work as they should. However since we do not know how to test the limits of its security measures we do not know for sure how secure these programs actually are. Overall, Privatix seems to be a very functional and portable distribution, allowing users access to standard applications for tasks such as editing and transporting data, sending/receiving email, instant messaging and multimedia applications with the added bonus of being completely secure and anonymous.

=Part 2=
==Software Packaging==
[[File:dpkg_out.png|thumb|right|Package listing, dpkg]]
[[File:aptitude_out.png|thumb|right|Package listing, aptitude]]
The packaging format that was used for the Privatix-Live System was DEB (based on the Debian packaging format). <ref name="privatix distrowatch">[http://distrowatch.com/table.php?distribution=privatix Privatix Distrowatch Page](Last accessed 12-11-11)</ref> The utilities used with this packaging format were dpkg and aptitude. Dpkg is used as the operating system's package management utility, with aptitude acting as the more user-friendly front end version. Aptitude made finding a list of installed packages quite easy. Aptitude allows you to see a full list of installed packages, with the packages being segregated into categories such as mail, web, shells and utils. As well as using aptitude, the command line can be used to access a list of installed packages. To do this, input the following in terminal and a list of all installed packages is generated. <ref name="dpkg man page">[http://manpages.ubuntu.com/manpages/lucid/man1/dpkg.1.html Dpkg Man Page](Last accessed 12-11-11)</ref>

$ dpkg -l

Though knowing how to do this in command line is useful, we found that using aptitude was generally better as the packages are segregated into categories which made viewing the list of installed packages more simple.

To add a package within Privatix, we found the easiest way was to use the one of the following commands provided by dpkg:

$ dpkg -i <package name>
or
$ dpkg --install <package name>

These commands function in the same way which means they will either install a package, or upgrade already installed versions of the package. <ref name="dpkg man page">[http://manpages.ubuntu.com/manpages/lucid/man1/dpkg.1.html Dpkg Man Page](Last accessed 12-11-11)</ref>

To remove a package within Privatix, we found the easist way was to use either of the following commands provided by dpkg:

$ dpkg -r <package name>
or
$ dpkg -P <package name>

When using "dpkg -r <package name>", everything related to the package ''except'' the configuration files are removed. To fully remove a package, however, we used "dpkg -P <package name>" which removes the entire package, including the configuration files. <ref name="dpkg man page">[http://manpages.ubuntu.com/manpages/lucid/man1/dpkg.1.html Dpkg Man Page](Last accessed 12-11-11)</ref>

We found that the software catalog for this distribution was quite extensive, especially since this distribution is meant to be portable. Privatix includes all the standard packages included with Debian (e.g. libc), as well as several other utilities meant to increase security and privacy while using the system such as IceDove, TOR and TORButton.

==Major Package Versions==

For this section of the report, we needed to determine how heavily modified by the distribution's author packages included within our distribution were. However, the distribution's author has stated that everything included is mainly based on Debian. <ref name="privatix documentation">[http://www.mandalka.name/privatix/doc.html Privatix Documentation (German)](Last accessed 12-11-11)</ref> The packages within Privatix have not been modified, the distribution's author has mainly brought together several security and privacy conscious utilities into one distribution for portable and daily use. As such, many of the packages that come with the standard install of Privatix have been included since they are included with the standard install of Debian at the time this distribution was made. Please also note that this reference was taken from the main page of the distribution but that, to view it, you will need to translate it (we used Google translate) as much of the documentation for this distribution is in German.

===Linux Kernel===
The packages relating to the kernel of the system we found were:
* linux-base: version 2.6.32-31
* linux-image-2.6.32-5-686: version 2.6.32-31
* linux-image-2.6-282: version 2.6.32+39

This version of the kernel was released in December of 2009, making it just under two years old. <ref name="linux kernel">[http://kernelnewbies.org/Linux_2_6_32 Linux Kernel v2.6.32 Info Page](Last accessed 12-11-11)</ref> The newest stable version of the Linux kernel was released just yesterday (11/11/2011), this version being listed as 3.1.1. <ref name="current kernel">[http://www.kernel.org/ Current Stable Linux Kernel](Last accessed 12-11-11)</ref> This puts the version of the Linux kernel on Privatix as being two years behind the current stable version of the Linux kernel. We believe that these packages were included within the distribution as they are the standard packages for the Linux kernel included in the standard install of Debian.

Please note that we treated these 3 packages as one entity as they pertained to the kernel. There was no upstream source (URL) included in the man pages of these packages.

===Libc===
The packages pertaining to libc that came with the standard install of Privatix we found were:
* libc-bin: version 2.11.2-10
* libc6: version 2.11.2-10

This version of libc was released in January 2011, making it approximately 11 months old.<ref name="eglibc">[http://packages.qa.debian.org/e/eglibc.html eglibc Source Package on Debian](Last accessed 12-11-11)</ref> This version is also the current stable version of libc, as listed on Debian. <ref name="eglibc">[http://packages.qa.debian.org/e/eglibc.html eglibc Source Package on Debian](Last accessed 12-11-11)</ref> However, a newer, unstable version (version 2.13-21), is currently undergoing testing. This package was included as it is also included in the standard install of Debian as well as that all Linux-based systems come with a version of libc.

The upstream source (URL) of these packages was [http://www.eglibc.org eglibc].

===Shell===
The version of the shell included with the standard install of Privatix was:
* bash: version 4.1-3

This version of bash was released in, approximately, April 2010. <ref name="bash">[http://packages.qa.debian.org/b/bash.html bash Source Package on Debian](Last accessed 12-11-11)</ref> It is also the current stable version of bash. <ref name="bash">[http://packages.qa.debian.org/b/bash.html bash Source Package on Debian](Last accessed 12-11-11)</ref> However, last month, version 4.2 of bash was pushed into testing and became the current experimental version.<ref name="bash">[http://packages.qa.debian.org/b/bash.html bash Source Package on Debian](Last accessed 12-11-11)</ref> This package was included as bash is the version of command line included with the standard install of Debian.

The upstream source (URL) of this package was [http://tiswww.case.edu/php/chet/bash/bashtop.html tiswww bash].

===Utilities===
For this section, we chose to study the busybox package included within the standard install. The package for busybox we found was:
* busybox: version 1:1.17.1-8

This version of busybox was released in, approximately, November 2010. <ref name="busybox">[http://packages.qa.debian.org/b/busybox.html busybox Source Package on Debian](Last accessed 12-11-11)</ref> It is also the current stable version of busybox as listed on Debian. <ref name="busybox">[http://packages.qa.debian.org/b/busybox.html busybox Source Package on Debian](Last accessed 12-11-11)</ref> This package was included as it the version of busybox included with the standard install of Debian.

There was no upstream source (URL) included within the man page of busybox within the system.

===Software Packaging===
The main utility used for package management within Privatix was dpkg. The version of dpkg included with the standard install of this distribution is:
* dpkg: version 1.15.8.10

This version of dpkg was released in February of 2011, making it 10 months old. <ref name="dpkg changelog">[https://launchpad.net/ubuntu/+source/dpkg/1.15.8.10ubuntu1 Dpkg Changelog](Last accessed 12-11-11)</ref> The current stable version of dpkg, as listed on Debian, is version 1.15.8.11 which was released in April of 2011. <ref name="dpkg">[http://packages.qa.debian.org/d/dpkg.html Dpkg Source Package on Debian](Last accessed 12-11-11)</ref> This would put the version of dpkg included with Privatix at 3 months behind the latest stable version. This package was included since dpkg is the package management system of Debian, the distribution that Privatix is based off of.

The upstream source (URL) for this package was [http://wiki.debian.org/Teams/Dpkg Dpkg on Debian]

===Web Browser===
'''IceWeasel'''

The web browser included with the standard install of Privatix is IceWeasel, with the version of IceWeasel being:
* iceweasel: 3.5.16-6

This version of IceWeasel was released in March 2011, making it 9 months old. <ref name="iceweasel">[http://packages.qa.debian.org/i/iceweasel.html IceWeasel Source Package on Debian](Last accessed 12-11-11)</ref> The newest stable version is version 3.5.16-11 which was released in November 2011. <ref name="iceweasel">[http://packages.qa.debian.org/i/iceweasel.html IceWeasel Source Package on Debian](Last accessed 12-11-11)</ref> This would put the version of IceWeasel included with Privatix at 9 months behind the latest stable release. IceWeasel was included within this distribution as it is a more security conscious browser than more mainstream browsers such as Mozilla Firefox. IceWeasel, an older version of GNU IceCat (a rebranding of FireFox), comes equipped with security features not available by default in FireFox.

There was no upstream source (URL) provided in the man pages the iceweasel package within the system.

'''TOR'''

The web browser also comes equipped with the program "The Onion Router" (TOR). The version of TOR that comes with the standard install of Privatix is:
* tor: 0.201029-1

This version of TOR was released in January 2011, making it 11 months old. <ref name="tor changelog">[https://launchpad.net/ubuntu/+source/tor/0.2.1.29-1 TOR Changelog](Last accessed 12-11-11)</ref> The latest stable release of TOR is version 0.2.1.30-1 which was released in July 2011. <ref name="tor">[https://launchpad.net/ubuntu/+source/tor TOR on LaunchPad](Last accessed 12-11-11)</ref> This package was included to help increase security, anonymity and privacy while web browsing which is one of the main goals of the Privatix distribution. For more information on TOR, see the Basic Operation section of the report, under Anonymous Web Browsing.

The upstream source (URL) provided with this package was [https://www.torproject.org TOR Project].

'''TOR Button'''

A program included to add to the functionality of TOR, is the TOR Button. The version of TOR Button that comes with the standard install of Privatix is:
* xul-ext-torbutton: version 1.2.5-3

This version of TOR Button was released in October 2010, making it just over a year old.<ref name="torbutton">[https://www.torproject.org/torbutton/ TORButton](Last accessed 12-11-11)</ref> The newest stable version of this program is version 1.4.4.1 which was released last month. <ref name="torbutton">[https://www.torproject.org/torbutton/ TORButton](Last accessed 12-11-11)</ref> This would put the version of TORButton included with Privatix at about a year behind the latest stable release. This package was included in order to add to the functionality of TOR. This add-on allows the user to enable and disable TOR with the push of a button, located in the corner of their browser.

The upstream source (URL) provided with this package was [https://www.torproject.org/torbutton/ TOR Button Project].

===Email===

The default email client provided with the standard install of Privatix is IceDove, with the included version being:
* icedove: 3.0.11-1+s

This version of IceDove is the current stable version as listed on Debian. <ref name="icedove debian">[http://packages.qadebian.org/i/icedove.html IceDove Source Package on Debian](Last accessed 12-11-11)</ref> However, this version was included within Privatix before it was made stable. It was released as an unstable version in December 2010 and was later released as the current stable version in October 2011. <ref name="icedove debian">[http://packages.qadebian.org/i/icedove.html IceDove Source Package on Debian](Last accessed 12-11-11)</ref> This email client was included due to the fact that it is a more security-conscious email client, providing government-grade security features, than others such as the regular version of ThunderBird. For more information on this program, refer to the Basic Operation section of this report under Secure Email.

There was no upstream source (URL) provided with this package.

===Other===
'''Pidgin'''

The default IM client included with the standard install of Privatix was Pidgin, with the version being:
* pidgin: 2.7.3.1+sq

This version of the Pidgin was released in October 2010, and is also the current stable version of Pidgin as listed on Debian. <ref name="pidgin">[http://packages.qa.debian.org/p/pidgin.html Pidgin Source Package on Debian](Last accessed 12-11-11)</ref> This package was included as Pidgin is the default IM client included with the standard install of Debian, the system on which Privatix is based.

The upstream source (URL) provided with this package was [http://www.pidgin.im Pidgin].

==Initialization==
[[File:init.png|thumb|right|List of Processes]]
Privatix generally follows the same initialization process as Debian. Privatix initializes by first executing first the BIOS then the boot loader code. <ref name="debian boot process">[http://wiki.debian.org/BootProcess#System_Initialization Debian Boot Process](Last accessed 12-11-11)</ref> Privatix uses the same boot loader as Debian which is System V initialization. /etc/inittab is the configuration file, with the /sbin/init program initializing the system following the description in this configuration file. <ref name="debian boot process">[http://wiki.debian.org/BootProcess#System_Initialization Debian Boot Process](Last accessed 12-11-11)</ref> inittab will set the default run level of Privatix, which is run level 2. Following this, all the scripts located in /etc/rc2.d are executed alphabetically. <ref name="debian boot process">[http://wiki.debian.org/BootProcess#System_Initialization Debian Boot Process](Last accessed 12-11-11)</ref> These scripts are:
* '''S01polipo''': polipo web cache--a small and fast caching web proxy
* '''S01rsyslog''': enhanced multi-thread syslogd which is Linux system logging utility
* '''S01sudo''': provides sudo
* '''S02cron''': starts the scheduler of the system
* '''S02dbus''': utility to send messages between processes and applications
* '''S02rsync''': opens rsync--a program that allows files to be copied to and from remote machines
* '''S02tor''': starts TOR (for more information, see above)
* '''S03avahi-daemon''': starts the zeroconf daemon which is used for configuring the network automatically
* '''S03bluetooth''': launches bluetooth
* '''S03networ-manager''': starts a daemon that automatically switches network connections to the best available connection
* '''S04openvpn''': starts openvpn service--a generic vpn service
* '''S05gdm3''': script for the GNOME display manager
* '''S06bootlogs''': the log file handling to be done during bootup--mainly things that don't need to be done particularly early in the boot process
* '''S07rc.local''': runs the /etc/rc.local file if it exists--by default this script does nothing, it is used only to exit
* '''S07rmologin''': removes the /etc/nologin file as the last step in the boot process
* '''S07stop-bootlogd''': runs the /etc/rc.local file again, if it exists--by default this script does nothing, it is used only to exit

Following this, the system is initialized.

We found this information by first confirming that Privatix used the same style of initializing as Debian. Once we ascertained this, we researched the Debian boot process. Privatix followed the same steps up until the loading of the scripts, which had some scripts that differed from Debian (e.g. TOR). Following this, we researched each of the scripts run on Privatix's default boot level of 2. The scripts are listed above, in the order they execute. To find the purpose of each of the scripts and what programs they opened, we manually went through each of the scripts.

=References=

<references />