==Accountable Virtual Machines ==
'''Authors:''' Andreas Haeberlen, Paarijaat Aditya, Rodrigo Rodrigues, Peter Druschel

'''Affiliates:'''
University of Pennsylvania, Max Planck Institute for Software Systems (MPI-SWS)]

'''Link to Paper:''' [http://www.usenix.org/events/osdi10/tech/full_papers/Haeberlen.pdf Accountable Virtual Machines]

==Background Concepts==

'''Accountable Virtual Machine (AVM)'''

'''Deterministic Replay''': A machine can record its executions into a file so that it can be replayed in order to see the executions and follow what was happening on the machine. Remus [[#References | [1]]] has contributed a highly efficient snap-shotting mechanism for these replays.

'''Accountability:''' Accountability in the context of this paper means that every action done on the virtual machine is recorded and will be used against the machine or user to verify the correctness of the application. The AVM is responsible of its action and will answers for its action against an auditor.

'''Remote Fault Detection:''' There are programs like GridCop[[#References | [2]]] that can be used to monitor the progress and execution of a remotely executing program by requesting a beacon packet. When the remote computer is sending the packets, the receiving/logging computer must be a trusted computer (hardware,software, OS) so that the receiving of packets remains consistent. To detect a fault in a remote system, every packet must arrive safely, and any interrupts during the logging must be handled or the inconsistencies will result in an inaccurate outcome. The AVM does not require trusted hardware and can be used over wide-area networks.

'''Cheat Detection:''' Cheating in games or any specific modification in a program can be either scanned[[#References | [3][4]]] for or prevented[[#References | [5][6]]] by certain programs. The issue with these scanning and preventative software is the knowledge/awareness of specific cheats or situations that the software can handle. An AVM is designed to counter any kind of general cheat.

'''Integrity Violations:''' This refers how the consistency of normal/expected operations of an execution does not equal to that of the host/reference (Trusted) execution, hence a violation has occurred.

- The word "node" is used to refer to a computer or server in order to represent the interactions between one computer and another, or a computer and a server.

=Research problem=

The research presented in this paper tries to tackle a problem that has haunted computer scientists for a long time. How can you be sure that the software running on a remote machine is working correctly or as intended. Cloud computing, online multi-player games, and other online services such as auctions are only a few examples that rely on a trust relation between users and a host. When a node (user or computer) expects some sort of result or feedback from another node, they would hope that that interaction being done would be independent of the node and only dependent on the intended software. Let's say, that node A interacts with node B with execution exe1 and node A interacts with node C also with ex1, but node C has been modified and respond with exe2. Thus, we can assume that the respond of B and C will be different. Being able to prove that the node C has been modified without any doubt is the purpose of this paper.

Previous work that has been done in efforts to prevent or detect '''integrity violations''' can be separated into different categories of operations. The first would be '''Cheat Detection''', where in many different games there are cheats that users use to usually create benefits for themselves that was not intended by the original game.[[#References |[4]]] These detectors are not dynamic, in the sense that they do not actually detect whether a cheat is being used, more so they are checking if there is a cheating operation that they have logged before, being operated on the user's system. For example, if there was a known cheating program named aimbot.exe that can be run in the background of a game such as CounterStrike, and the PunkBuster system that was implemented on the user's system had the aimbot.exe program already logged as a cheating program from the developers, the PunkBuster program might notify the current game servers of this or even prevent the user from playing any games until the aimbot.exe operation is no longer running.

'''Accountability''' is another important problem that many have already worked on. The main goal of an accountable system is to be able to determine without a doubt that node is faulty and can prove it with solid evidence. It can also be used to defend a node when threatened with false accusation. Numerous systems already use accountability in their system, but they were mostly all linked to specific applications, where a point of reference must be used to compare. As example PeerReview[[#References |[7]]], which is a system closely related to what the research team have worked on, must be implemented into the application which makes it less portable and cannot be implemented as easily as an '''AVM'''. PeerReview verifies the inbound and outbound packets and can see if the software is running as intended.

Another problem that is related to the paper is '''remote fault detection''' in a distributed system. How can we determine if a remote node is running the code correctly or if the machine itself is working as intended. Network activity is a common solution to this problem, as they look at the inbound and outbound of the node. This can let them know how the software is operating, or in the case of AVM how the whole virtual machine is working. Gridcop[[#References |[8]]] is another example that inspects a small number of packets periodically. Another way of determining the fault remotely is to use a trusted node, where it can tell immediately if a fault occurs or a modification is made where it should not have been made.

The problem of logging and auditing the processes of an execution of a specific node (computer) is greatly dependent on the work done for '''deterministic replay'''. Deterministic replay programs can create a log file that can be used to replay the operations done for some execution that occurs on a node. Replaying the operations done on the node can show what the node was doing, and this would seem like it is sufficient in finding out whether a node was causing integrity violations or not. The concept of snap-shoting/recording the operations is not the issue with deterministic replay, it is the fact that the data being outputted into the replay may be tampered with by the node itself so that it generates optimal results in replay. By faking the results of the operations, the auditing computer will falsely believe that the tested computer is running all operations as normal. The logging operations done by these recording programs can be directly related to the work needed to detect integrity violations.

=Contribution=
The accountable virtual machine (AVM), that was proposed in this essay, most useful contribution was the implementation of the accountable virtual machine monitor (AVMM). It is what allows for the fault checking of virtual machines in a cloud computing environment. The AVMM can be broken down into different parts: the virtual machine monitor (VMM), the temper-evident log, and auditing mechanisms. The VMM is based off the VMM found in VMWare Workstation 6.5.1[[#References |[9]]], the temper-evident log was adapted from code in PeerReview[[#References |[7]]], and the audit tools were built up from scratch.

The accountable virtual machine monitor relies on four assumptions:

1. All transmitted messages are received, retransmitted if needed.

2. Machines and Users have access to a hash function that is pre-image resistant, second pre-image resistant, and collision resistant.

3. All parties have a certified keypair, that can be used to sign messages.

4. To audit a log, the user has a reference copy of the VM used.
The job of the AVMM is to record all incoming and outgoing messages to a tamper-evident log
and enough info of the execution to enable deterministic replay.

The hash function used is a cyrptographic hash function, which is a way of translating a arbituary block of data into a string. While not impossible to spoof or break, if it has the three properities specified in the assumptions it is concidered a "hard" problem that is infeasible for a malicious attacker to use as a attack vector in the foreseable future, and thus is secure.

The AVMM must record nondeterministic inputs (such as hardware interrupts), because the input is asynchronous, and the exact timing of input must be recorded so the inputs can be injected at the same moment during the replay. Wall-clock time is not accurate enough for this recording, so the AVMM must use a combination of instruction pointer, branch counter, and additional registers. Not all inputs have to be recorded this way (software interrupts) because they send requests to the AVM, which will be issued again during replay.

Two parallels streams appear in the tamper-evident log: message exchanges and nondeterministic inputs.
It is important for the AVMM to detect inconsistencies between the user's log and the machine's log (in case of foul play), so the AVMM simply cross-references messages and inputs during replay, thus, easily detecting any discrepancies.

The AVMM periodically takes snapshots of the AVM's current state, this facilitates fine-grain audits for the user, but it also increases overhead. The overhead is lowered slightly by the snapshots being incremental (only save the state that has been changed since the last snapshot). The user can authenticate the snapshot using a hash tree of the state (generated by the AVMM) and it can update the hash tree after each snapshot.

'''Tamper-Evident Log'''

The log is made up of hash code entries.
Each log entry in form e = (s,t,c,h)
s = monotonically increasing sequence number
t = type
c = data of the type
h = hash value

The hash value is calculated by: h = H(hi-1 || s || t || H(c))
H() is a hash function.
|| stands for concatenation

Each message sent gets signed with a private key, when the AVMM logs the messages with the signature attached but removes it before sending it to the AVM. To ensure nonrepudiation, an authenticator is attached to each outgoing message.

To detect when a message is dropped, each party sends an acknowledgement for each message they receive. If an acknowledgement is not received the message is resent a few times, if the user stops receiving messages, then the machine is presumed to have failed.

To preform a log check, the user retrieves a pair of authenticators, then challenges the machine to produce the log segment between the two. The log is computationally infeasible to edit without breaking the hash chain, thus, if the log has been tampered with, the hash chain will be different and the user will notified of the tampering.

'''Auditing Mechanism'''

From VMM's perspective all things are deterministic.

To perform a audit, the user:

1. obtains a segment of the machine's log and the authenticators

2. downloads a snapshot of the AVM at the beginning of the segment

3. replays the entire segment, starting from the snapshot, to verify the events in the log are the correct execution of the software.

The user can verify the execution of software through three different methods: Verifying the log, snapshot, and execution.

When the user wants to verify a log segment, the user retrieves the authenticators from the machine with the sequence numbers in the range of the log segment. The user then downloads the log segment from the machine, and, starting with the most recent snapshot before the log segment and ending with the most recent snapshot before the end of the log segment. The user then checks the authenticators for tampering. If this step proceeds, the user can assume the log segment executed properly. If the machine is faulty, the segment will be unavailable to download or may return a corrupted log segment. This can be used to convince a third party of the fault.

When the user wants to verify the snapshot, the user obtains a snapshot of the AVM's state at the beginning of the log segment. The user then downloads a snapshot from the machine and the AVMM recomputes the hash tree. The new hash tree is compared to the hash tree contained in the orignal log segment. If any discrepancies are detected, the user can use this to convince a third party of the machine's faults.

In order for the user to verifying the execution of a log segment, the user needs three inputs: the log segment, the snapshot, and the public keys of the machine and any users of the machine. The auditing tool performs two checks on the log segment, a syntactic check (determines if log is well-formed), and a semantic check (determines if the information in the log shows the correct execution of the machine).

The syntactic check checks whether all log entries are in the proper format, the signatures in each message and acknowledgement, if each message was acknowledged, and the sequence of sent and received messages is correct when compared to the sequence of messages that enter and exit the AVM.

The semantic check creates a local VM that will execute the machine's log segment, the VM is initialized with a snapshot from the machine if possible. The local VM then runs the log segment and the data is recorded. The auditing tool then checks the log segments, inputs, outputs, and verification of snapshot hashes of the replayed execution against the original log. If any discrepancies are detected then the fault is reported and can be used as evidence against the machine.

=Critique=

The layout of the paper is primordial for the comprehension of the reader. The introduction clearly describes what the reader has to expect in the following pages, especially what problems are addressed and how they are solved.

This paper gives multiple examples about advantages and disadvantages in an AVM. A good example is "Cheat Detection". Cheaters use programs to go around the original game code to gain an major advantage over other players. Since an AVM is generic in cheat detection it has a wider support for detecting cheats than most of the other cheat detection algorithms. The logs give the game the function to replay the game. Thus, players using AVM can see the way other players play by replaying the game with the player's log.

The negative side is that the player might have to suffer from the AVM. Everything is being logged and stored on the hard drive, which takes a lot amount of space. In the example in the paper it is 148mb per hour after compression. This reduces the fps. Additionally, the connection to the AVM increases the ping time to the server.

As a proof of concept, they used their AVM in the online game Counter Strike and tried to detect online cheats. They were using “Dell Precision T1500 workstations, with 8 GB of memory and 2.8 GHz Intel Core i7 860 CPUs”[pg 10]. These machines are considerably more high powered than the system requirements of Counter-Strike, which are “500 MHz processor, 96 MB RAM”[10]. A 10 year old game [10] should use fewer resources on a Dell Precision T1500 workstations. In comparison, newer games consume far more resources than Counter-Strike giving it less room to run the AVM. A 13% slowdown [pg 12.] in a game where you are only getting 30 to 40 fps is a pretty noticeable slowdown. This is very detrimental to the game play because having over 60fps is the optimal performance.

In the paper the authors state that the AVM will only generate an extra 5ms of latency. While this does not seem like a lot the measurement was taken over a LAN with all the computers connected to the same switch [pg. 12]. This sample does not accurately represent real life situations and therefore lacks external validity, since many of these online games are played over the internet with the participants sometimes not even on the same continent; the latency overhead of the AVM would certainly increase due to the added distance. [12]

Additional Critiques:

While the paper does test a slightly larger than one to one scenario, it certainly does not test in a real world environement where 16,32 or even 64 players would be playing in the sametime.

Spot checking can be used for applications that require snapshots every x seconds. Even if this way remove a lot of overhead and data storage, it only verify if the applications or user is working as intended every x second. Thus, someone could find the patern of those snapshots and render the AVM inutile.

AVM's are extremely effective against two types of cheating, that which gives incorrect networking messages and the one that has to be loaded with the game. This is the perfect world for tournaments competition type of game, but in a real world this wouldn't be of much use. Games get patched, users download add-ons for the game, etc. Every patch or add-ons would require a new AVM which is unreasonable for the amount of people playing the game. A solution brought from the team was to disable the right to install anything on the AVM. As this could work in a tournament environment, a normal users at home would not be pleased with this limitation.

An AVM's will not in any way catch any bug or exploit in a program that a malicious user could exploit, as the exploit would appear on both user/monitor systems and perform the same.

For their use case, the authors did not state that in counterstrike the user can record a demo of his current game. Some online playing leagues require every player to record his own demo and upload it to the website, where every person in the league can watch it. Without this demo the team lost the match immediately. Additionally, some leagues require the player to start an extra program (e.g. Electronic Sports League WIRE), which checks the programs running in the background. It also takes random snapshots of the current player and compresses all information into a file and uploads it to one of the server in the online league, where it can be checked by any player.

=References=
[1] B. Cully, G. Lefebvre, D. Meyer, M. Feeley, N. Hutchinson, and
A. Warfield. Remus: High availability via asynchronous virtual
machine replication. In Proceedings of the USENIX Symposium
on Networked Systems Design and Implementation (NSDI), Apr.
2008.

[2] S. Yang, A. R. Butt, Y. C. Hu, and S. P. Midkiff. Trust but
verify: Monitoring remotely executing programs for progress
and correctness. In Proceedings of the ACM SIGPLAN Annual
Symposium on Principles and Practice of Parallel Programming
(PPoPP), June 2005.

[3] G. Hoglund. 4.5 million copies of EULA-compliant spyware.
http://www.rootkit.com/blog.php?newsid=358.

[4] PunkBuster web site. http://www.evenbalance.com/.

[5] N. E. Baughman, M. Liberatore, and B. N. Levine. Cheat-proof
playout for centralized and peer-to-peer gaming. IEEE/ACM
Transactions on Networking (ToN), 15(1):1–13, Feb. 2007.

[6] C. M¨onch, G. Grimen, and R. Midtstraum. Protecting online
games against cheating. In Proceedings of the Workshop on Network
and Systems Support for Games (NetGames), Oct. 2006.

[7] A. Haeberlen, P. Kuznetsov, and P. Druschel. PeerReview: Practical
accountability for distributed systems. In Proceedings of
the ACM Symposium on Operating Systems Principles (SOSP),Oct. 2007.

[8] S. Yang, A. R. Butt, Y. C. Hu, and S. P. Midkiff. Trust but
verify: Monitoring remotely executing programs for progress
and correctness. In Proceedings of the ACM SIGPLAN Annual
Symposium on Principles and Practice of Parallel Programming
(PPoPP), June 2005.

[9] VMWare Workstation 6.5.1 web site. http://www.vmware.com/products/workstation/

2010-11-27T15:20:53Z

2010-10-14T18:47:52Z

Jbaubin: /* Answer */

==Question==

There have been multiple attempts to have operating systems use databases or database-like stores. What have been some of the major past attempts at this? What was their fate? Why? Key examples (not exhaustive): WinFS, ReiserFS, PalmOS, Newton OS, BeOS

==Answer==

There have been many attempts at creating file systems that use database-like stores. While the idea is an interesting one, database stores are just not ready for the consumer market.

Traditionally, databases are used in applications where a project focuses on accessing large amounts of data quickly and efficiently, such as banking systems, telecommunications, and web servers. A personal computer did not traditionally need as much storage, and is organized in an easy-to-navigate tree structure. However, the recent shift towards object-oriented programming styles, along with the tremendous increase in the amount of data that can be stored on a home computer, has led to the idea of object stores, or file systems that function as databases of objects [http://homeostasis.scs.carleton.ca/wiki/index.php/COMP_3000_Essay_1_2010_Question_11].

There have been various implementations of object stores in the real world, all chosen for certain features that made sense in that application. For PalmOS and NewtonOS, the security and modularity object stores provided was an attractive fit for mobile devices. Windows was drawn to object stores because of the possible speed increases, and so they developed WinFS. ReiserFS seemed to have started as a proof-of-concept, which found it's place with Linux.

Object stores have caught on in a few niche applications, mostly scientific. However, this technology is in its infancy, still trying to engineer issues that are arising while implementing the concept. Combined with issues with management that surround most attempts at creating an object store, it is clear that object stores are a long way off from becoming a common file system.

**For the last two paragraphs did you mean database-like stores?**

**What about something like this ?

There have been many attempts at creating file systems that use database-like stores. While the idea is an interesting one, database stores are just not ready for the consumer market.
Traditionally, databases are used in applications where a project focuses on accessing large amounts of data quickly and efficiently, such as banking systems, telecommunications, web servers and more. A personal computer did not traditionally need as much storage, and is organized in an easy-to-navigate tree structure. However, the recent shift towards object-oriented programming styles, along with the tremendous increase in the amount of data that can be stored on a home computer, has led to the idea of object stores, and file systems that function as databases.

There have been various implementations of operating system that use a database as file system , all chosen for certain features that made sense in that application. We’ll visit 5 differents operating systems that used a database as file system. First palmOS used database mainly for efficiently. WinFS was a file system for the operating system Windows that used database for efficiently too. NewtonOS was produced to be used on a desktop machine, but then became one of the best operating system for pda with a very good security. BeOS was a new operating system and decided to use a database for file system because of efficiently and for compability reason. ReiserFS was more of an experience that turned into a new file system using database. We will first examine the trials of PalmOS.
**

==Palm OS==

===History===
PalmOS was developed from Graffiti, a hand-recognition software which was believed to be doomed from the very beginning[http://www.iam.unibe.ch/~rvs/teaching/SS02/bs/arbeiten/Guido_Gloor-PalmOS.pdf]. Graffiti’s fast and accurate hand-recognition software was thought to be useless because many companies did not see a purpose for it; there were no companies that wanted to make the hardware for it[http://www.iam.unibe.ch/~rvs/teaching/SS02/bs/arbeiten/Guido_Gloor-PalmOS.pdf]. The company Palm then decided to make their own hardware with Graffiti as the OS, which became what is known as Palm OS today.

===Database Structure===
Palm OS does not use a relational or XML database[http://www.iam.unibe.ch/~rvs/teaching/SS02/bs/arbeiten/Guido_Gloor-PalmOS.pdf]. Instead Palm OS has two different database types, record and resource database. There are similarities between these two databases, they both have headers which stores information onto the database and are both stored in the storage heap. The difference between the record database and resource database is how the information is stored, called, handled and how it is named. The record database is used to store data, and the resource database contains all applications.

Furthermore a record database is a collection of records (blocks of memory) each record can only store up to 64KB of memory. It has information that is unique to the record; it has the location of the record, an ID, and an attribute, which contains delete, dirty, busy, and secret bits [book ref].

The resource database stores application code, name, icon, forms, alerts, menus, strings, and all other elements of the application [book ref]. Applications can be referenced by an ID number and a type (four-character constant).

===Problem===
Record and resource databases are stored in storage/database heap, which in turn is stored in the RAM (Random Access Memory). The database heap has a limit of 64KB of memory and since a record had to be small enough to fit within the heap, this made memory hard to manage. For example, when a record is 50KB and there are three heaps which can only hold 64KB each, a total of 192KB of memory; say these three heaps are half full therefore there is 96KB of free memory, but the record of size 50KB cannot be stored because not a single heap has enough memory to store the record. [book ref] This problem arose in versions before OS 3.0 because the database heap was divided into smaller parts. This allowed for free space in memory, but some of those heaps were occupied by data, and there might not be enough space to store the record into the heap. Palm OS 3.0 and later solved this problem by to making a single large storage heap instead of multiple smaller heaps.

===Fate===

In 2005, Palm OS was acquired by Access Systems Americas, Inc. Access decided to expand the breadth of the operating system’s offering to include more tools, a better user experience, and increased compatibility across many more devices.[http://azul.iing.mxl.uabc.mx/~renecruz/papers/Unpublished-Cruz-Flores-2.pdf] In 2007, development of Palm OS shifted to a new operating system called Garnet OS. [http://www.access-company.com/products/platforms/garnet/index.html] Its latest release, Garnet version 6, still includes a database based file system.

==WinFS==

===History===

The history of WinFS is relatively long, as we can find trace of the project back in mid-90's with Storage +. Microsoft had the idea to remove the NTFS file system and instead use a relational object-oriented file storage, which was based on SQL server 8.0. This new file system was supposed to be implemented in Windows 2003 Server. But then in 2000, Windows announced that Storage + was to be forgotten, with Relational File System (RFS) as its successor. RFS was supposed to be included in SQL Server 2000, but never made the cut. Another reason for the continual delays was that, in 2000, Oracle announced a new file system which was also a relational file system, Independent Internet File System. Microsoft had to rethink RFS to be ahead of the competition and that added additional delay.[http://www.winsupersite.com/showcase/winfs_preview.asp]

RFS was forgotten about until the public heard in 2002 about a new file system that would be present in Longhorn (later renamed Vista). The system would be once again be based on its predecessor, RFS, but it would have run on top of a NTFS file system. WinFS was included in a few public builds for Vista, but in 2004 it was removed from the beta builds. It was said it would be downloadable again after the release, but was definitely cut for good in 2006 from Vista.

===Brief Concept===

With today’s data, we are facing a crisis of finding what we want, when we want, at a reasonable speed on our own computer. Data is stored in many different ways. We can recognize the uses of certain files by their file extensions, but the amount of file extensions that exist is astonishing, so it is quite difficult to remember each one. Also, a simple file may be stored with different extensions, in different databases, which makes finding, relating to, and acting on the file quite difficult to achieve. [http://www.slideshare.net/Severus/winfs]

Microsoft had an idea to solve this problem by using a relational database as a file system, where data would be treated like it should be, as data and nothing else. To understand how WinFS works, we must have a general idea of the relational database. The data in this kind of database is spread into specific tables, like in a normal database, but there are multiple relations between these tables. This gives the programmer the power to search, find and present the result in an efficient way. In the case of WinFS, the main goal was to "Enable people to Find, Relate, and Act on their information"[http://msdn.microsoft.com/en-US/library/aa480687.aspx].

As already pointed out, data files are very broad nowadays. With that many file formats using complicated data storage methods, the "...current file system does not know how to collect and find information within these new types of data"[http://msdn.microsoft.com/en-US/library/aa480687.aspx], but with data treated as data inside a database, we could find what we are looking for quite easily.

Another important point of WinFS is the notion of how data relates to each other. In our current file system we can't, unless doing it manually, add a picture of our good friend Bob, and in the same time see all the picture related to Bob. On top of that, we can't find the picture of Bob, all the received emails, documents, movies, or whatever else we would want to find in the same request. In order to find them, we have to search for them one by one. If we treat data as data, once again, we can simply search in the tables of the database for the pictures, received emails, videos, and documents containing the name Bob, and present them to the user. As we can see, data can be related to each other with keywords, in our example it was the name Bob, but it can be anything.[http://channel9.msdn.com/Blogs/scobleizer/Shishir-Mehrotra-WinFS-beta-1-team-meeting]

The last problem that WinFS was aiming to overcome was to run on top of NTFS. Basically, WinFS would scan all the data in the NTFS file system, and put it into its database. Thus, it would work as a file system, but it would be totally dependent of NTFS.

===Fate of WinFS===

As we have seen in the history of WinFS, its fate wasn't as desired. In 2006, on the team blog, Microsoft announced that it wouldn't include WinFS as a system file package, but instead deliver it into the next Microsoft SQL server, which was SQL Server 2008. "These changes do mean that we are not pursuing a separate delivery of WinFS, including the previously planned Beta 2 release"[http://blogs.msdn.com/b/winfs/archive/2006/06/26/648075.aspx], but instead, they will keep working on it and some "...may be used by other Microsoft products going forward."[http://blogs.msdn.com/b/winfs/archive/2006/06/26/648075.aspx] So, we can see that WinFS didn't succeed as a file system, but some of the logistics will continue to live on in Microsoft’s database software.

===Why===

Microsoft never released publicly what exactly went wrong. There was much speculation about the design of WinFS, but on the team blog Quentin Clark, Product Unit Manager of WinFS, answered that "[i]n fact, the Beta was coming together really well."[http://msdn.microsoft.com/en-US/library/aa480687.aspx] He then replied that the technology used wasn't easy to build onto, so they had to rewrite some parts, but that this wouldn't have caused the end of WinFS. Some also speculate that no serious software used WinFS, nor did it receive the attention needed from the developers to have a good start. In an interview with Channel 9, Quentin Clark said, "We were building too much of the house at once. We had guys working on the roof while we were still pouring concrete for the foundation."[http://channel9.msdn.com/blogs/jonudell/where-is-winfs-now] This shows that the team might have had some management problem, which evidently led to the termination of the project.

==Newton OS==

===Brief History of Newton OS===

Newton OS was created by Apple and was used with their line of PDAs, becoming one of the world's first PDAs. Newton was originally meant to be an innovative OS to reinvent personal computing, but it was changed to become a PDA, due to fear of eating up Macintosh sales and because of project delays [http://www.techeblog.com/index.php/tech-gadget/a-look-back-apple-newton]. The first iteration of the Newton system came as the MessagePad. The MessagePad sold out its 5,000 copies within a few hours of release, despite its price of $800 US [http://www.pencomputing.com/frames/newton_obituary.html]. Apple released several different PDAs with Newton OS between 1993 and 1997, which despite its popularity were plagued by flaws in the applications of the device [http://news.cnet.com/Apple-scraps-Newton/2100-1001_3-208551.html].

The main reason why Newton PDAs became so well-known was because the Newton OS was the most advanced operating system of any personal computing device of its time. The OS kept the user from accessing the inner workings of the device, keeping users away from creating problems by tampering with the wrong settings, and used a database-based file management that simplified the system to a higher degree than any previous OS [http://www.pencomputing.com/frames/newton_obituary.html].

===Flaws of Newton OS===

Even with the innovation that came from Newton OS and its computing devices, it had several deep-running flaws that caused critics to pan the Newton devices. First and foremost, the Newton devices were known for their failure at implementing their handwriting system, which was supposed to recognize entire words. The Simpsons television show even had a joke about this flaw in one of their episodes [http://www.youtube.com/watch?v=xc3JzS0K3ys]. The main problem behind the handwriting system was that it had a hard time recognizing cursive writing, even though Apple insisted that its engineers ensured it worked correctly [http://www.roughlydrafted.com/RD/Q4.06/600D65E6-A31E-45CA-AFC5-42BC253F5337.html]. Another main problem with the Newton devices was that their overall size was too large for most pockets. Since Newton devices were expected to be carried similarly like a wallet or a cellphone, most people found their size too great for daily use [http://news.cnet.com/8301-13512_3-9754359-23.html][http://www.roughlydrafted.com/RD/Q4.06/600D65E6-A31E-45CA-AFC5-42BC253F5337.html]. Earlier Newton devices were also found to be very slow due to the virtualization of the NewtonScript and the lack of necessary RAM [http://www.roughlydrafted.com/RD/Q4.06/600D65E6-A31E-45CA-AFC5-42BC253F5337.html]. In the end, the Newton devices were fated to fail.

**I dont think the sentence with the simpsons part is a good idea because it is not likely for essays to have something like that**

===Fate===

Although the Newton OS was revolutionary when it was released, it was doomed to fail due mostly to impracticality. In early 1997, Newton Inc. was created as a subsidiary company of Apple [http://findarticles.com/p/articles/mi_m0EKF/is_n2169_v43/ai_19494161/], but after a relatively short run, Newton Inc. was reabsorbed into Apple [http://findarticles.com/p/articles/mi_m0EKF/is_n2189_v43/ai_19892982/]. In December of 1997, Apple effectively ceased development efforts on the Newton OS [http://news.cnet.com/2100-1001-206664.html], and in February 1998, Apple announced the discontinuation of the Newton OS development [http://www.apple.com/ca/press/1998/02/NewtonDisco.html].

===Why===

After his return as CEO of Apple, Steve Jobs canceled or restructured many of Apple's failing products to refocus Apple's energy towards more successful endeavors, like the iPod and Macintosh computers. Not surprisingly, Newton OS was one of these products [http://www.roughlydrafted.com/2010/01/26/steve-jobs-apple-tablet-%E2%80%9Cthe-most-important-thing-ive-ever-done%E2%80%9D/]. Although Newton was canceled, the development of the OS and its devices have had impacts on other Apple products. Mac OS X 10.2 has a handwriting recognition software called Inkwell that uses an external tablet to recognize words, but like the Newton handwriting software, it requires you to right each letter individually [http://lowendmac.com/osx/jaguar-10.2/index.html][http://everything2.com/title/Inkwell]. Pixo, the company that created the operating system for the iPod, was founded by two of the developers that worked on the Newton OS [http://www.starmenusa.com/blog/category/Culture][http://articles.sfgate.com/2004-08-16/business/17438885_1_pixo-user-interface-ipod]. Pixo was subsequently acquired by Apple after the shipping of the first iPods [http://www.servinghistory.com/topics/Pixo].

==BeOS==

===Brief History===

BeOS is released by Be, Inc which is founded in 1990 by Jean-louis Gasee and Steve Sakoman. Be OS is a brand new operating system running on it’s own hardware called BeBox. The system is giving a better performance on digital media works because of better use on system resources. This system is initially made for AT&T Hobbit hardware, but since AT&T decide to stop producing Hobbit processor, the system is modified to Apple’s PowerPC hardware.

===Operating System===

===File System===
The file system used by BeOS is called BFS. BFS is a custom file system developed by the same team as BeOs. BFS is a 64-bit journaling file system which logs all data before storing it. [http://www.citeulike.org/user/msakai/article/638204] This journaling increases both the stability and security of BeOs, by preventing system crashes from jeopardizing the file system’s integrity as well as offering quicker recovery from crashes. However, this comes at the expensive of rapid data acess since a journaling file system is based on random memory access. Uniquely, the BFS journaling file system was implemented by BFS to be a high performance file system that stores all data in a database, but also allows users to view it in a more traditional heirachical way. [http://www.letterp.com/~dbg/practical-file-system-design.pdf] It also boost flexibility by allowing users to store any possible data format of their choosing.

Since BFS is a custom file system developed solely to be used by BeOs its success is intrinsically tied to that of its operating system. BeOs poses a threat to BFS both because of its inability to reach the masses as well as the potential memory errors caused by its unfiltered multithreading capability. Because, system reliability is placed in the hands of the programmer, BeOs's multithreading capability is a potential cause for concern especially when combined with a slow access file system.

===Fate===
The fate of BeOS

Microsoft execlusive lisence with hardware manufacture made harder to enter the market

==ReiserFS==

===History===
ReiserFS is the product of Namesys, a Californian company stared by Hans Reiser [http://web.archive.org/web/20071024001500/http://www.namesys.com/v4/v4.html]. ReiserFS was first introduced in version 2.4.1 of the Linux kernel, and was the default file system on several Linux distributions, most notably SUSE. ReiserFS's successor is Reiser4, which released in 2004[http://en.wikipedia.org/wiki/Reiser4]. However, in 2008, Namesys dissolved and commercial production of ResierFS and Reiser4 halted [http://news.cnet.com/8301-13580_3-9851703-39.html]. Since the removal of commercial support, ReiserFS has become less popular, probably due to the many bugs that have no hope of being resolved.

===Concept===
ReiserFS is driven by a few major concepts. The first and probably main idea is the ability to handle many files that are smaller than a block of storage on the storage media. This is accomplished through the use of B+ Trees. [http://delivery.acm.org.proxy.library.carleton.ca/10.1145/610000/603630/6267.html?key1=603630&key2=4060996821&coll=ACM&dl=ACM&CFID=105645345&CFTOKEN=72691832]. Instead of balancing in order to keep the height of the tree fairly stable (as an AVL tree balances), ReiserFS balances so that the height of the storage tree is constant. This type of balanced tree reduces overhead by reducing the number of internal nodes, or i-nodes needed. Each node in the B+ tree maps to a block on the storage device, and each node can hold multiple objects, each of which has a unique key[http://homes.cerias.purdue.edu/~florian/reiser/reiserfs.php]
Another concept in ReiserFS is the use of unified name spaces[http://www4.informatik.uni-erlangen.de/Lehre/WS01/PS_KVBK/docs/reiserfs/MosheBarReiserFS.pdf]. Unified name spaces are simply a more refined definition of an object store, in which all stored data is made up of objects that are both 'files' and 'directories'. Objects are stored in such a way so that you can use directories to quickly access different types of objects, then further traverse the directories in order to access specific objects, and go even further to access an object's attributes. This maps extremely well to different programming styles, especially object oriented programming. Lookup of data can also done using attributes of the data, much like in WinFS[http://homeostasis.scs.carleton.ca/wiki/index.php/COMP_3000_Essay_1_2010_Question_12#WinFS]. This type of access would be more often used by the end user.

===Flaws and Fate===
While ResierFS preforms very well in terms of speed [http://www.sun.com/software/whitepapers/solaris10/fs_performance.pdf], ReiserFS has many bugs that can lead to instability of files. One problem is that link() and unlink() are not synchronous in ReiserFS, which can lead to data corruption[http://archives.neohapsis.com/archives/postfix/2001-05/1749.html]. Another is that, if ReiserFS's tree structure becomes unusable for any reason, a rebuild risks further corrupting the file system [http://lkml.indiana.edu/hypermail/linux/kernel/0506.3/0219.html]. There are also issues with the journaling which can lead to corruption [http://users.cis.fiu.edu/~yangz/teaching/reading_list/Analysis%20and%20Evolution%20of%20Journaling%20File%20Systems.pdf]. Issues like these are a bad idea in any file system, as the risk of unstable data is a serious drawback. Considering that the root of these issues are often synchronization problems, ReiserFS is a very poor choice for many modern, multi-core systems, as the increased need for synchronization would increase the level of instability.

In addition to the stability issues, ReiserFS has some design issues mainly contribute to why it is no longer used today. Since ReiserFS was designed to handle numerators small files, when trying to scale a ReiserFS system, behavior is inconsistent, again spawning from issues in synchronization. In addition, moving from the bug-ridden ReiserFS v3 to v4 required a reformat, as Reiser4 was re-written from scratch. This prompted SUSE to drop ReiserFS as it's default file system, as they preferred to use a tried and tested sytem update (ext3) instead of a new, yet-untested file system in their distribution [http://lwn.net/Articles/202780/].

Interestingly enough, the SUSE drop coincided eerily well with Hans Reiser being sent to jail. Left without an owner, Namesys lost most corporate sponsors, eventually only receiving funding from the DARPA initiative. With Namesys (mostly) gone, ReiserFS no longer has commercial support, and so the stability and scalability bugs are taking a fair amount of time to be resolved. This combined with low visibility that stems from no longer being used in any major Linux distributions largely explains why ReiserFS can be considered a dead project.

==Conclusion==
Looking at these object based file systems, it is easy to see that, despite object stores being an interesting and potentially useful idea, they are just not ready yet for the desktop. For certain applications, such as systems designed to handle large amounts of data for programming projects, such as ones used for models in physics; or in small, modular systems such as PalmOS and NewtonOS, object stores are a great alternative to the traditional file system. However, there has not yet been developed a highly flexible design that would be useful on the average PC, as we can see from the failure of WinFS and ReiserFS.

The increasing importance of digital information in today's world also means that people are extremely reluctant to switch a tried and true system for newer and possibly unstable technology. In the case of object stores, what few implementations are available to the public for the desktop are unstable, and therefore an unattractive choice.

It is important to note that object stores are not the only alternative file system competing to improve upon traditional block storage[http://homeostasis.scs.carleton.ca/wiki/index.php/COMP_3000_Essay_1_2010_Question_9], so there is no guarantee that object stores will ever become a widely used technology, as they may not mature quickly enough to beat out other technologies.

==Reference==
[1] Palm OS programming: the Developer’s guide by Neil Rhodes, Julie McKeehan

http://membres.multimania.fr/microfirst/palm/pdb.html

http://mobile.eric-poncet.com/palm/tutorial/db.html

COMP 3000 Essay 1 2010 Question 12

2010-10-14T18:00:50Z

Jbaubin: /* Brief Concept */

COMP 3000 Essay 1 2010 Question 12

2010-10-14T17:59:01Z

Jbaubin: /* Brief Concept */

COMP 3000 Essay 1 2010 Question 12

2010-10-14T17:58:29Z

Jbaubin: /* Brief Concept */