What is Nitro?
==============

Nitro is a tool for reporting application crashes, providing
developers with useful information for debugging, such as the core
dump. The collected crash data is sent to a post-processing server over
the network. It provides roughly similar functionality as tools such
as Bug-buddy and Apport do on desktop Linux distributions, although
Nitro has a somewhat more minimal user interface.


Basic usage:
============

Nitro should usually come with a pre-set valid configuration, so after
installation it should be immediately possible to start using
it. Nitro can be enabled or disabled with its own Control Panel applet
that gets installed at the same time as the tool itself.

If core dumps from previous application crashes are already available
on memory card when Nitro is started, a dialog will pop up, listing
the number of core files and asks whether user wants to send them to
the post-processing server for analysis. If user answers "No", the
cores will not be deleted from the memory card. Nitro will ask this
question each time it starts, including immediately after boot. If
user merely wants to get rid of the cores without sending them, they
can safely be removed via File Manager.

When an application or a process crashes, user will see a dialog
popping up, containing a message roughly like the following:

"The application 'Media Player' crashed. The system can send a core
file for analysis. Send core?"

Options are fairly self-describing:

- 'Send' will attempt to send the current core dump to the
  post-processing server. After the core has been successfully sent, it
  will be deleted from the memory card.

- 'Delete' will remove the current core from the memory card.

- 'Cancel' will just close the dialog and do absolutely nothing
  concerning the core dump.

For system processes that are not applications launchable via the Task
Navigator, Nitro UI will be display the name of the actual (rich-)core
dump file instead, i.e. something like 'icd2-11-3322.rcore.lzo',
because it cannot map the name of crashed executable into a more
human-readable application name.


Configuration:
==============

For configuration settings related to communication between the Nitro
client and a Nitro post-processing server, see README contained in the
'nitro-settings' package.

For configuration settings related to privacy, see "Related tools"
section in this document or the documentation contained by
'sp-rich-core' package.


Related tools:
==============

While Nitro could also in principle work with ordinary core dumps, the
crash data available for developers (only the traditional UNIX core
dump) would be rather limited. Thus, Nitro depends on 'sp-rich-core'
package. When sp-rich-core is enabled (which happens by default when
it's installed), additional information such as syslog (if available),
memory usage information, process states and list of installed
packages are also included in the data dump (which can be recognized
from the .rcore.lzo suffix). Sp-rich-core package provides more
information about this in the form of rich-core-dumper (1) manual
page. The manual pages also describe how to configure the amount of
collected data in order to adjust to individual privacy preferences.


Short technical summary:
========================

The Nitro client consists of two parts; the daemon and the UI. Of
these, only the daemon will be running constantly when Nitro is
installed. The daemon monitors known locations for the cores
(/media/mmc1/core-dumps and /media/mmc2/core-dumps directories) by
using GnomeVFS. The daemon uses HTTPS for communication with the
post-processing server.

The UI will be invoked by the daemon when it detects that system has
new cores in the aforementioned locations ready to send to the
post-processing server. After the step chosen by the user has been
completed, the UI component will exit to conserve resources.


Links
=====

 http://directory.fsf.org/project/bugbuddy/
 https://wiki.ubuntu.com/Apport
