language cleansing

1 files changed, 18 insertions, 18 deletions

diff --git a/analisys.mdwn b/analisys.mdwn
index 66c0267..8a6534d 100644
--- a/analisys.mdwn
+++ b/analisys.mdwn
@@ -1,18 +1,18 @@
-# Analisys
+# Analysis
 
-For those who need a detailed explanation about what RSP is and why it can be useful, the following sections covers the economic aspects of resource sharing for system administration.
+For those who need a detailed explanation about what RSP is and why it can be useful, the following sections cover the economic aspects of resource sharing for system administration.
 
 # The Problem
 
-Sometimes free software projects face resource crisis than can be understood as a lack of means to keep their efforts going on, but at the same time can be understood as a crisis of the current paradigm of organization (maybe both technological and social).
+Sometimes free software projects face a resource crisis than can be understood as a lack of means to keep their efforts going on, but at the same time can be understood as a crisis of the current paradigm of organization (maybe both technological and social).
 
-That happens especially with softwares which are part of the long part of the tail and if they're not willing to use a too much standardized hosting service such as Sourceforge or Googe Code.
+That happens especially with softwares which are part of the long part of the tail and if they're not willing to use a too much standardized hosting service such as Sourceforge or Google Code.
 
-Maybe wouldn't be too hard to do a paradigm shift, not a profund but one that can address the current precarity of the server infostructure.
+Maybe wouldn't be too hard to do a paradigm shift, not a profound one, but one that can address the current precarity of the server infostructure.
 
-Some kind of coordination/organization and/or even a standard or protocol can help to to facilitate the resource sharing because currently things are done more or less loosely among different groups that share things -- not exactly because people are "loose" but maybe because that was the way that worked very well until the community realize that they need something better -- and then things can get easily messed with stuff such as no one knowing whether some system is updated, has backups or how older are the disks happening most of the time.
+Some kind of coordination/organization and/or even a standard or protocol can help to to facilitate the resource sharing because currently things are done more or less loosely among different groups that share things -- not exactly because people are "loose" but maybe because that was the way that worked very well until the community realizes that they need something better -- and then things can get easily messed with stuff such as no one knowing whether some system is updated, has backups or if the disks are failing.
 
-For groups which depend on servers, its possible to frame the problem in an economic fashion, where we consider the some limited resources, usually like
+For groups which depend on servers, its possible to frame the problem in an economic fashion, where we consider some limited resources, usually like:
 
 * Servers
    * Bandwidth
@@ -33,11 +33,11 @@ When such things happen, the groups pass from an accumulation "level" to another
 
 The current way groups organize their resources usage might be insufficient to protect them from multiple different threats (data loss, centralization, etc).
 
-Maybe this happen because they're still not so used to share they physical resources. Sharing a software sollution is way easier because one just needs to make a regular package and give it to people, while sharing concurrent/rival resources seens to be a lot more complex.
+Maybe this happens because they're still not so used to share they physical resources. Sharing a software solution is way easier because one just needs to make a regular package and give it to people, while sharing concurrent/rival resources seens to be a lot more complex.
 
-So, in short: a resource crisis can be seem as a failure to organize the resource usage inside a group or among a group of groups. While groups are partially successfull is sharing non-rival goods (protocols, software, configurations, and partially because its possible to do it better), they are still failing in sharing our concurrent/rival resources like disk and bandwidth.
+So, in short: a resource crisis can be seem as a failure to organize the resource usage inside a group or among a group of groups. While groups are partially successfull is sharing non-rival goods (protocols, software, configurations, and partially because its possible to do it better), they are still failing in sharing our concurrent/rival resources like diskspace and bandwidth.
 
-It's not just a way to just have a big server and create a lot of vservers and give it to groups because a sollution that scale in a way that can be easily manageable and don't need more workload is still needed.
+It's not just a way to just have a big server and create a lot of vservers and give it to groups because a solution that scales in a way that can be easily managed and doesn't need more workload is still needed.
 
 Each group usually can take care physically of just one or two servers/racks in the same or different locations. But having just servers in two locations is still not so safe, so an easy way to share this physical resource would be to let other groups give and get virtual spaces inside the real boxes. This way, a group with just one server can have lots of virtual spaces in friend's groups.
 
@@ -47,7 +47,7 @@ Some "alliance" assumes some sort of mutual benefit -- altough there are groups
 
 Usually, replication of virtualization technologies consists basically of backing up both the server space and the configuration needed to run it. There are advantages and disadvantages of each virtualization platform (vserver uses a lot less resources while other platforms allows running things in kernel mode like file system encryption independently from the host).
 
-Considering a group that requests virtual space and depending in the use the group want to give, it doesn't matter too much whether their virtual space uses technology X or Y (as virtual spaces are intented to act as independent servers anyway).
+Considering a group that requests virtual space and depending in the use the group want to give, it doesn't matter too much whether their virtual space uses technology X or Y (as virtual spaces are intended to act as independent servers anyway).
 
 So a general "Virtualization Alliance" could be formed by
 
@@ -70,16 +70,16 @@ As an example, for backup purposes, we could consider the following options:
    * Groups that hosts virtualized environments and do not make backups of them. 
 * Internal backups: those made from inside a virtual environment to somewhere else made by the hosted group. 
 
-Note that its possible that a given virtual environment be backed up by both "external" and "internal" methods, they're not mutual excludent methods.
+Note that its possible that a given virtual environment be backed up by both "external" and "internal" methods, they're not mutual exclusive methods.
 
 # Labor
 
 There's also some other parameters to consider: how much labor is needed to keep a server running? Considering a debian box with vservers, how much work is needed to:
 
 * Install/reinstall a system?
-* Keep the system up to date.
-* Change configurations.
-* Emergencies. 
+* Keep the system up to date?
+* Change configurations?
+* Emergencies?
 
 Sure these points depend in the configuration (eg. with puppet perhaps the cost of install/reinstall falls to near zero). Crossing this information with the nummber of available people (and how much work they can do) can help to shape if the group is ready to have more boxes.
 
@@ -96,7 +96,7 @@ If the problems is restricted just to virtualized environments, a lot of effort
 
 Maybe there are groups that can do all, but we can assume that these are three big types of labor so we'll have groups that can/want to do just one, two or all these jobs. So the problem would be to combine these resources and specializations together.
 
-In order to integrate groups working at different "levels" and allow then to share resources, lets start thinking about layers and a protocol to help then to share things among different layers.
+In order to integrate groups working at different "levels" and allow then to share resources, lets start thinking about layers and a protocol to help them to share things among different layers.
 
 # Layer-based replication
 
@@ -140,12 +140,12 @@ Layers can be even virtual: consider the equivalence of these two systems:
     | Machine |
     |_________|
 
-Then, for a layer sit on top of one or another system there's not much difference in terms of property inheritance.
+Then, for a layer sitting on top of one or another system there's not much difference in terms of property inheritance.
 
 # How RSP fits into all this mess
 
 The RSP can be used to help the groups:
 
-* Evalue their available resources and possible uses for it, like establishing classes of resources with similar metadata which fits sets of uses.
+* Evaluate their available resources and possible uses for it, like establishing classes of resources with similar metadata which fits sets of uses.
 * Inform other groups about the resources they have and need.
 * Set their layer/replication policy.