Complete the "How to use Firstaidkit" section.

1 files changed, 13 insertions, 46 deletions

diff --git a/doc/articlefak-concept.tex b/doc/articlefak-concept.tex
index ea7f61a..7e5431d 100644
--- a/doc/articlefak-concept.tex
+++ b/doc/articlefak-concept.tex
@@ -17,61 +17,28 @@ On the following Monday he gets help from the informatics office in his universi
 /section{ What is Firstaidkit }
 Firstaidkit is an automated recovery tool that brings together common recovery processes and applies them to a system.  The way that Firstaidkit handles the recovery processes is by means of plugins.  The idea being that a plugin will focus on a particular issue in the system, like grub, init scripts or xserver.  Firstaidkit is designed to automatically fix problems while focusing on maintaining user data integrity.  In other words, Firstaidkit will try its best to fix your system while maintaining your data intact.
 Here we can recall Joe's situation.  Lets recreate the end of the story with the only difference being that Joe had Firstaidkit on a rescue disk or liveCD.  Joe just wants his computer to boot, he knows that he somehow shot himself on the foot, but now he would want an easy way out.  In this case Joe may run Firstaidkit in diagnose mode to see what is wrong with his system.  Firstaidkit will notice the missing grub in the first 512 bytes of the drive and will tell Joe that he needs to fix his grub.  After looking through the Firstaidkit man pages and searching through the plugin list, Joe finds that he needs to run the plugin named "grub".  He tells Firstaidkit to run grub in fixing mode and reboots his machine after the process ends.  He waits impatiently for the machine to go past the blank screen with the cursor at the top left.  When the computer boots normally, Joe is very pleased that all his information was not lost and continues his daily activities.
-Joe's situation is just one of many in which an automated recovery tool would make peoples life easier.  It is not restricted to the linux user that is a beginer and can be extended into administrator recovery tasks like a Selinux analysis process, deleted partition recovery process, init scripts recovery, rpm database recovery, etc.  The list extends into most, if not all, the OS subsystems.
-But unfortunatelly Firstaidkit will not take care of everything.  Being a tool that executes common recovery processes, it needs some context from the existing system to actually get the fix right.  If you completely wipe out your hard drive it will be extremely difficult for Firstaidkit to get anything done.
+Joe's situation is just one of many in which an automated recovery tool would make peoples life easier.  It is not restricted to the linux user that is a beginner and can be extended into administrator recovery tasks like a SELinux analysis process, deleted partition recovery process, init scripts recovery, rpm database recovery, etc.  The list extends into most, if not all, the OS subsystems.
+But unfortunately Firstaidkit will not take care of everything.  Being a tool that executes common recovery processes, it needs some context from the existing system to actually get the fix right.  If you completely wipe out your hard drive it will be extremely difficult for Firstaidkit to get anything done.
 
 /section{ How does Firstaidkit work? }
-Firstaidkit can be considered a list of recovery processes that can be used to recover default value behavior.  Most of the time the user will not be looking to do a full system check.  Instead a specific subsystem is identified as misbehaving and therefor targeted to be rescued.  The trick here is for the user to know how that misbehavior is referenced in Firstaidkit.  More specifically, what subsystem it relates to.  When a machine does not boot the failure can be in a lot of places, but to the user its one problem: My computerr does not boot.  Each plugin will have a diagnose that will give the user important information about current state and hopefully point the user in a direction where he can find more information.  So when the user runs a diagnose of the sytems messages like "Your initscripts are busted" and "You are missing a boot loader" will jint the user that the problem of his computer not booting is really related to his init scripts and bootloader.  Moreoverr, if the user is using a our GUI to he will be presented with red messages advising him of missbehaving subsystems.
-Firstaidkit is based on a plugin framework.  Each plugin is a recover process that allows different recovery processes to be added to the system with little or no effort.  The Firstaidkits user interface (UI) presents a list of these plugins and the user must decide the way in which they will be executed.  The plugins can be run in a fully automated way.  This means that all the plugins will be run and there will be an attempt to fix whatever issue is encountered.  This approach is not reasonable considering the amount of plugins that could exist at a certain point.  Imagine running 30 or 40 plugins when all you really need is to change your root password.  Additionally, there is no real need to run all of the plugins because the user will have some idea of what the problem is.
-Another, more rational way of interacting with the system is to pick what plugins will run.  Firstaidkit allows the user to see the description of each plgin and decide based on said description the plugins that are needed.  This prevents the user from having to execute all the plugins when all he needs is a simple recovery task.
-So how does the user that knows very little about the system take advantage of the possibility to pick a plugin?  He could run all the plugins in diagnose mode, this mode will not take any action but will tell the user if a specific subsystem is working properly or not.  After making a diagnose only run, the user has information that could be used to actually decide what plugins to run.
-Firstaidkit is controlled by ini style configuration files.  The system allows to pull any number of configuration files from various places.  It also allows the user to specify individual configuration values through the CLI.  This way of pulling configuration values from various places can get complicated, so Firstaidkit has the ability of printing the resulting configuration after parsing all the files.
-The philosophy of Firstaidkit is to be a *fully* automated recovery system.  This means that once plugin execution has started there is no user interaction.  Everything must be specified in the configuration files or command line.
-At this point it is important to note that Firstaidkit can be run in environments different from a healthy running system.  This is needed because Firstaidkit will probably be used in situations where a healthy running system is not an option.  There are two additional ways of getting to Firstaidkit:
+The philosophy of Firstaidkit is to be a *fully* automated recovery system.  This means that once plugin execution has started there is no user interaction.  Everything must be specified in the configuration files, CLI or GUI.
+Firstaidkit can be considered a list of recovery processes that used to recover default value behavior.  Most of the time the user will not be looking to do a full system check.  Instead a specific subsystem is identified as misbehaving and therefor targeted to be rescued.  The trick here is for the user to know how that misbehavior is referenced in Firstaidkit.  More specifically, what subsystem it relates to.  When a machine does not boot the failure can be in a lot of places, but to the user its one problem: My computer does not boot.  Each plugin will have a diagnose that will give the user important information about current state and hopefully point the user in a direction where he can solve the problem or find more information.  When the user runs a diagnose of the systems, messages like "Your initscripts are busted" and "You are missing a boot loader" will hint the user of the real root of the problem.  Moreover, if the user is using our GUI, he will be presented with red messages advising him of misbehaving subsystems.  This general diagnose can be the first step in the rescue process.
+After the general diagnose the logical next step is to actually fix something.  Firstaidkits plugin based framework give the user many ways of doing this.  Each plugin is a recover process in itself, they can be chosen to run individually, a group of plugins can be chosen to execute in one run, special parameters can be given to individual plugins, some plugins can have various fix methods while others can be restricted to a default behavior.  The plugin framework allows this diversity while still having a default behavior for the user that does not want to customize behavior.  Basically the user must specify the plugins to be run, the initial configuration values (they are specified in a config file) and that all the plugins are to be run in fixing mode.
+After executing the plugins, Firstaidkit goes and does its magic.  While executing, it shows the user what is being done in the system by means of a log that is redirected to stdout or a file.  The GUI can also show the log in a very efficient way, coloring the warnings and errors in a matter in which the user can clearly see where stuff went wrong.  All this recollected information is important for the user to know what was done to the system and can be used in cases Firstaidkit is not able to fix the related subsystem.
+Another nice thing about the plugin framework is the possibility of adding individual plugins from other sources.  Lets say your distribution does not provide the SELinux plugin that another distribution might have.  The only thing that needs to be done is to copy all the related plugin files or directories and point firstaidkit to the place where they reside.  Since they can be executed independently from each other there will be no interference if you run them individually.
+Currently there are two ways of interacting with Firstaidkit: The Command Line Interface (CLI) and the Graphical User Interface (GUI).  Both of them have different ways of doing the same things, basically present the related information and provide means of executing plugins.  The GUI is the easiest way of interaction but also depends on lots of the subsystems, an X server being the most prominent.  But when the problem is not the X server, you can choose plugins, start execution, stop execution and modify various configuration variables from the GUI.  This way of interaction has a built in log filter that colors the warnings and errors accordingly to emphasize various states of the fixing process.  This is something that non experienced users will appreciate.  There is another downside to the GUI besides the dependency on the X server, its not scriptable.  There might be a situation where a sysadmin might want to create a general system diagnose script.  He may think it useful to run every time he does an update or does major changes on a system.  The GUI cannot aid the sysadmin in his task, but the CLI is a perfect fit for this kind of situation.  In summary the CLI and the GUI complement themselves and increase the user satisfaction for various types of users.
+Some of Firstaidkits behavior is controlled by ini style configuration files.  The system allows to pull any number of configuration files from various places.  It also allows the user to specify individual configuration values through the CLI and GUI.  This way of pulling configuration values from various places can get complicated, so Firstaidkit has the ability of printing the resulting configuration after parsing all the files.
+At this point you might have guessed the importance of running Firstaidkit on a damaged system.  This is needed because Firstaidkit will probably be used in situations where a healthy running system is not an option.  There are two additional ways of getting to Firstaidkit:
 
 /begin{ itemize }
 /item Rescue image:
-To use the rescue functionality of the iso images is the most logical thing to do when your system is not well.  Specially if it does not boot.  Firstaidkit will be contained in the rescue image and can be accessed with the command line.  Note that there is no X in rescue mode.  This means that the only way of interacting with Firsaidkit is through command line interface.
+To use the rescue functionality of the iso images is the most logical thing to do when your system is not well.  Specially if it does not boot.  Firstaidkit will be contained in the rescue image and can be accessed with the command line.  Note that there is no X in rescue mode.  This means that the only way of interacting with Firsaidkit is through CLI.
 /item Live CD:
-Live CD fits in really nice with the firstaidkit concept because it puts the user in a graphical environment without the need of a sane local system.  This gives Firstaidkit the opportunity to be in a place where the user can interact with its GUI.  Making life for the user easier.  Everything that applies for the command line applies for the GUI.  The user can activate the recovery processes that he thinks are needed or just tell Firstaidkit to make a general scan of the system.
+Live CD fits in really nice with the firstaidkit concept because it puts the user in a graphical environment without the need of a sane local system.  This gives Firstaidkit the opportunity to be in a place where the user can interact with its GUI.  The user can activate the recovery processes that he thinks are needed or just tell Firstaidkit to make a general scan of the system.
 /end { itemize }
 
-/section{ Firstaidkit capabilities }
-Lets go into more detail on Firstaidkit's plugin capabilities and at the same time we can discuss some features that it has for plugin developers.  Firstaidkit on its own does nothing interesting with respect to fixing things.  It needs the plugins to do the fixing.  Firstaidkits backend is the one in charge of making all the plugins work together.  Things like logging, coordinating plugin order, backup files and data are all the job of the backend.  The plugins have access to most of this backend and can use a lot of cool functionalities to get their job done.  So, what does the backend have that can be used in the plugins?  here is a list that has a short description of the functionalities:
+/section{ Conclusion }
 
-/begin{itemize}
-/item logging: It allows communication with the user.  Its the preferred way of telling the user what is being done to the system.
-/item backup: Easy way of backing up files, directories and data.
-/item plugin order: The plugin may define what system state needs to be present for the plugin to run correctly.
-/item issues:
-/item flow: This is a way of defining the automatic _activities_ in a plugin.
-/item parameter: Defines how parameters are passed to plugins.
-/end{itemize}
 
 /end{document}
 
-Initial Brainstorm:
-
-To whom am I writing this article?  Developers or users, or both?
- * I should write an article for developers.
- * and another for users.
-
-What is my main idea and message?
- * Transmit what a great concept the firstaidkit is.
- * Transmit the ease of use of firstaidkit.
- * Transmit the ease of development.
- * Tell everyone what firstaidkit is.
- * How can firstaidkit be used.
- * What is the current state of firstaidkit.
- * What is in the future for firstaidkit.
- * Answer a bunch of questions and put the document together.
-
-This should be a short an consise document.  Easy readable and understandable.  To the point.
-
-
-
-WHAT DOES IT TARGET?
-It targets everything that renders any part of the system unusable.
-
-RANGE(SCOPE)
-FAK's scope is quite big as it has the possibility to aid in the recovery of most, if not all, the subsystems of the OS.