* A-A-P is portable over many systems. At least most Unix variants, MS-Windows and possibly the Macintosh. * A-A-P is open source, free software. Most of it is under the GNU GPL. Interfaces and libraries are more free. * A-A-P is not a monolitic program. It is made out of separate modules with clear interfaces. Most of the work is done by existing tools. * Since network connections are slow and unreliable - and when using a laptop - a local copy of a file is often required. A-A-P caches files, obtains a new version when available and cleans up files that have not been used recently. * The more alternatives there are, the more choices a developer has to make. Making all these choices slows down development. Therefore A-A-P provides a preferred set of modules. Many people will be satisfied with most of these modules, but will still be able to use a different module where they have a preference. * A-A-P is available in a command-line version and in a GUI version. The command-line version works on a console and over a telnet connection. The GUI version is easier to use, but requires a windowing system. * A-A-P maintains a set of preferences. These are global to all projects but local to the user or system. This specifies where specific tools, libraries, documentation files, etc. can be found. This greatly reduces the need to configure a package when building or installing it. * English is used in the original code. Provisions are made to add translations through the use of message files. * Reliability is considered more important than fancy features. A-A-P is a tool you can rely on.

* The Bcfg2 server is responsible for taking a comprehensive infrastructure description and turning it into a series of configuration specifications for particular clients. It also manages probed data and tracks statistics for clients. The Bcfg2 server takes information from two sources when generating client configuration specifications. The first is a pool of metadata that describes clients as members of an aspect-based classing system. That is, clients are defined in terms of aspects of their behavior. The other is a file system repository that contains mappings from metadata to literal configuration. These are combined to form the literal configuration specifications for clients. * The Bcfg2 client attempts to reconcile the current configuration state with the configuration passed down from the server using various client tools. It does not perform any processing of the target configuration description. * Bcfg2’s reporting system is its killer feature. It allows administrators to gain a broad understanding of the configuration state of their entire environment. It summarizes * Configuration changes and when they were made * Discrepancies between the specification and current client states * Clients can be grouped by misconfiguration type * Configuration entries that are not specified * Overall client summaries according to these types