Create the "Conclusion" section.

	modified:   doc/articlefak-concept.tex

1 files changed, 18 insertions, 5 deletions

diff --git a/doc/articlefak-concept.tex b/doc/articlefak-concept.tex
index 7e5431d..391f4ed 100644
--- a/doc/articlefak-concept.tex
+++ b/doc/articlefak-concept.tex
@@ -23,22 +23,35 @@ But unfortunately Firstaidkit will not take care of everything.  Being a tool th
 /section{ How does Firstaidkit work? }
 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.
+After the general diagnose the logical next step is to actually fix something.  Firstaidkit's 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 starting the plugin execution, 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.
+Some of Firstaidkit's 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 CLI.
+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 Firstaidkit 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.  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{ Conclusion }
-
+/begin[ itemize }
+/item Firstaidkit is an automated recovery tool that brings together common recovery processes.
+/item Firstaidkit is based on a plugin backend.
+/item Firstaidkit has a GUI and a CLI.
+/item There are situations where having Firstaidkit is relevant.  Joe's problem just being one of many examples.  It can also be used by sysadmins as a diagnose and/or recovery tool.
+/item It aids the user in precarious situations.  It ads to a good user experience.
+/item It has no interaction with the user once it begins to execute.
+/item It can be use to diagnose a system.  This diagnose can be performed by means of scripts and/or using the GUI.
+/item When doing the diagnose and/or fixing, it will inform the user of relative information of the system and process being applied to the system.
+/item The user can select individual plugins and execute them as preferred.
+/item The user can execute Firstaidkit in a running system, in rescue mode, and on the liveCD.
+/item The GUI increases the understanding of the log messages.
+/item It is highly configurable and can handle more than one configuration source.
+/item The inclusion of a plugin in the pool is as easy as copying the plugin file or directory.
 
 /end{document}