Free metrics software for linux

Perl::Metric::Basic is a Perl module that can provide basic software metrics.

SYNOPSIS

# first construct a PPI::Document object to pass in
my $document = PPI::Document->load("t/lib/Acme.pm");

# then retrieve metrics on the document
my $m = Perl::Metric::Basic->new;
my $metric = $m->measure($document);

# $metric will consist of something like:
# Acme => {
# new => {
# blank_lines => 1,
# comments => 1,
# lines => 7,
# lines_of_code => 6,
# numbers => 0,
# numbers_unique => 0,
# operators => 3,
# operators_unique => 2,
# symbols => 5,
# symbols_unique => 2,
# words => 7,
# words_unique => 6
# },
# ...

When constructing software one often produces code of vastly differing quality. The Perl::Metric::Basic module leverages the PPI module to provide some interesting software metrics for Perl code, mostly measuring size and maintainability.

A metric is some sort of measurement which is intended to help you make a decision about a piece of code. There arent any hard rules about metrics, but the ones provided should allow you to make decisions about modules or subroutines which are outliers. Abnormal measurements in a subroutine are a warning sign that you should reexamine that routine, checking for unusually low quality.

This module uses the PPI module, and thus can parse Perl code without evaluating it.
If youre interested in software metrics, I highly recommend "Code Complete" (Second Edition) by Steve McConnel (Microsoft Press).

METHODS

new()

The new() method is the constructor:
my $m = Perl::Metric::Basic->new;

measure()

The measure() method measures some metrics and returns a hash reference. Files in Perl can contain more than one package, and it is interesting to seperate metrics by package. The key for the hash reference is the name of the package, and the value is another hash reference.

Perl packages are seperated into subroutines, and it is interesting to seperate metrics by subroutine. The key for the second hash reference is the name of the subroutine, and the value is another hash reference containing metrics.

There are various metrics applied to the subroutine. The key for the third hash reference is the name of the metric, and the value is the value of the metric. The metrics are:

blank_lines

The number of blank code lines.

comments

The number of lines containing comments.

lines

The total number of lines.

lines_of_code

The number of lines of code.

numbers

The total number of numbers used (eg "$z = 42 * 3" would have 2 numbers).

numbers_unique

The number of unique numbers used (eg "$z = 2*$x + 2*$y" would have 1 unique number).

operators

The total number of operators used.

operators_unique

The number of unique operators used.

symbols

The total number of symbols used (eg "$z = $x*$x + $y*$y" would have 5 symbols).

symbols_unique

The number of unique symbols used (eg "$z = $x*$x + $y*$y" would have 3 unique symbols).

words

The total number of words (operators) used.

words_unique

The number of unique words used.

EnterTrack project is a Web-based artifact tracking/management system.

EnterTrack provides large organizations with complete tracking of artifacts (artifacts can be problems, bugs, requests, projects, etc.), group collaboration for artifact management, and status reports for high-level performance metrics.

Codestriker project is an open-sourced web application which supports online code reviewing. Traditional document reviews are supported, as well as reviewing diffs generated by an SCM (Source Code Management) system and plain unidiff patches.
There are integration points with CVS, Subversion, Clearcase, Perforce, Visual SourceSafe and Bugzilla. There is a plug-in architecture for supporting other SCMs and issue tracking systems.
Using Codestriker for your reviews minimizes paper work, ensures that issues, comments and decisions are recorded in a database, and provides a comfortable workspace for actually performing code inspections.
An optional highly-configurable metrics subsystem allows you to record code inspection metrics as a part of your process.
Codestriker is written in Perl, and runs on all of the major platforms and browsers, and is licenced under the GPL.
Configuration
This section is concerned with unpacking the Codestriker distribution into a suitable location, and then configuring it. For UNIX distribution, the following commands may be appropriate on your system:
% mkdir /var/www/codestriker
% cd /var/www/codestriker
% tar zxvf /from/installed/location/codestriker-X.Y.Z.tar.gz
% chown -R apache.apache /var/www/codestriker/codestriker-X.Y.Z
Here "apache" is the user which runs the Apache server. It could be "nobody" under different systems. Check with the ps auxww command, or check your Apache configuration files. Under Windows, the Codestriker distribution could be unzipped into a suitable location under c:program files, or just c:codestriker.
The next task is to edit the codestriker.conf configuration file to reflect the settings on your site. The file is documented with examples to assist in setting appropriate values. The file is in Perl syntax, so lines starting with a # indicate a comment.
Enhancements:
- The project list screen now displays, for each project, the total number of open topics and the total number of topics.
- Clicking on the count will go to the topic list screen with the relevant topics displayed.
- The VSS repository handler has been modified so that topics can be created by labels or version numbers in the start and end tag fields.
- The URI filter in the Template Toolkit changed its behaviour in 2.16, which was responsible for generating invalid links.
- This has now been fixed.
- There is better handling of Subversion diffs that were generated on non-English systems.

FTimes is a system baselining and evidence collection tool. FTimess primary purpose is to gather and/or develop information about specified directories and files in a manner conducive to intrusion analysis.
FTimes is a lightweight tool in the sense that it doesnt need to be "installed" on a given system to work on that system, it is small enough to fit on a single floppy, and it provides only a command line interface.
Preserving records of all activity that occurs during a snapshot is important for intrusion analysis and evidence admissibility. For this reason, FTimes was designed to log four types of information: configuration settings, progress indicators, metrics, and errors. Output produced by FTimes is delimited text, and therefore, is easily assimilated by a wide variety of existing tools.
FTimes basically implements two general capabilities: file topography and string search. File topography is the process of mapping key attributes of directories and files on a given file system. String search is the process of digging through directories and files on a given file system while looking for a specific sequence of bytes. Respectively, these capabilities are referred to as map mode and dig mode.
FTimes supports two operating environments: workbench and client-server. In the workbench environment, the operator uses FTimes to do things such as examine evidence (e.g., a disk image or files from a compromised system), analyze snapshots for change, search for files that have specific attributes, verify file integrity, and so on. In the client-server environment, the focus shifts from what the operator can do locally to how the operator can efficiently monitor, manage, and aggregate snapshot data for many hosts. In the client-server environment, the primary goal is to move collected data from the host to a centralized system, known as an Integrity Server, in a secure and authenticated fashion. An Integrity Server is a hardened system that has been configured to handle FTimes GET, PING, and PUT HTTP/S requests.
The FTimes distribution contains a script called nph-ftimes.cgi that may be used in conjunction with a Web server to implement a public Integrity Server interface. Deeper topics such as the construction and internal mechanics of an Integrity Server are not addressed here.
Main features:
- FTimes is easy to use and fast! The rest is pure gravy...
- FTimes has been written in C and ported to many popular OSes such as AIX, BSDi, FreeBSD, HP-UX, Linux, Solaris, and Windows 98/ME/NT/2K/XP. FTimes does not require additional runtime support such as a script interpreter (e.g., Perl) or a Virtual Machine (e.g., JVM).
- FTimes does not need to be installed on the clients machine. In many cases it can be run from a floppy or CDROM. Because of this, FTimes can be configured such that it is minimally invasive to the target system. This is important when trying to collect evidence of an attack on a live system.
- FTimes has thorough logging. This helps to increase its credibility and admissibility as evidence because the log information can be used to determine the known or potential error rate of the tool under various conditions. FTimes logs four types of information: configuration settings, progress indicators, metrics, and errors.
- FTimes detects and encodes non-printable characters (e.g., white space, carriage returns, etc.) in filenames. This ensures that your view of the output is not artificially altered by the data you are looking at. The URL encoding scheme used also helps you to quickly focus in on anomalous filenames.
- FTimes detects and processes Alternate Data Streams (ADS) when running on Windows NT/2K/XP systems. This is quite useful in cases where the perpetrator has used Alternate Data Streams to hide tools and information.
- FTimes output is delimited ASCII, and therefore, is conducive to analysis. This output can be assimilated using standard database technology as well as a wide array of existing tools. This makes it more flexible than proprietary database schemes that are essentially opaque to the practitioner. Ultimately, this format yields better analysis results because the practitioner is able to manipulate data freely, and peers may independently verify analysis results. Again, this helps to strengthen its credibility and admissibility as evidence.
- FTimes can be deployed as an enterprise solution with all information being transmitted to and preserved on a hardened Integrity Server. This allows for centralized management of data, and avoids the problem of leaving data exposed on a clients system. Data stored on a clients system is vulnerable to malicious modification or destruction.
- FTimes natively supports client initiated HTTP/HTTPS uploads/downloads. This eliminates the need for boundary devices such as firewalls to have a special inbound connection rules. Furthermore, theres a good chance that existing boundary devices already support the required outbound communications path because it is the same as that needed to browse the Web.
- FTimes provides an efficient string search capability (a.k.a. dig mode). This is particularly useful in investigations when the practitioner has a profile of key words or byte strings that are likely to exist somewhere on the target system.
- FTimes optionally supports device file digging (block/character).
- FTimes output is configurable on a per attribute basis. This allows users to develop data in a way thats best suited to their needs.
- FTimes optionally produces directory hashes. This is a significant analysis advantage in situations where content rarely changes. The advantage is that one hash effectively represents the content of all directories and files contained in a given tree.
- FTimes optionally produces symlink hashes.
- FTimes optionally performs file typing via XMagic. When there are hundreds or thousands of unknown hashes, it is difficult to determine which files may have changed as a result of a malicious act. In these situations, type information can be used to categorize files and prioritize the order in which they are examined.
- FTimes has an extremely fast, tunable compare capability. This enables the practitioner to quickly analyze snapshots and determine change.
Enhancements:
Version 3.8.0 is a minor release of FTimes. Generally, code was cleaned up and refined as necessary. Several bugs have been fixed -- see the ChangeLog for details. This release includes support for SHA256 hashes, include/exclude filters, and a number of additional file systems (DATAPLOW_ZFS, NTFS-3G, NWCOMPAT, UDF). HashDig utilities have been updated to support SHA1 and SHA256 hashes, and the
following tools have been been added to the project:
ftimes-crv2dbi.pl, ftimes-dig2dbi.pl, hashdig-find.pl, and tarmap. Note that documentation is no longer built at release time, and that means your build system must include the necessary tools to create the documentation -- see the Requirements Section in README.INSTALL for additional details. Since SF officially discontinued compile farm support on 2007-02-08, this project is no longer able to build/test releases in the manner and scale that it did before. Unfortunately, this may result in platform-specific issues that go unnoticed until they are discovered by someone in the field.

WebService::TestSystem is a Perl module with Web service for implementing a distributed testing system.

my $testsys = new WebService::TestSystem;

# Getting a list of tests foreach my $test (@{$testsys->get_tests()}) { print "$test->{id} $test->{descriptor}n"; }

# Getting a list of hosts foreach my $host (@{$testsys->get_hosts()}) { print "$host->{id} $host->{descriptor}n"; }

# Submitting tests my %request; if (! $testsys->validate_test_request(%request) ) { my %errors = $testsys->get_validation_errors(); } else { my $test_request_id = $testsys->request_test(%request); print "Test request #$test_request_id submittedn"; }

# System Metrics @metrics = $testsys->metrics_test_run_time(2004, 12); @metrics = $testsys->metrics_requests_per_month(2004, all) @metrics = $testsys->metrics_distros_tested_per_month(2004) etc.

WebService::TestSystem presents a programmatic interface (API) for remote interactions with a software testing service. In other words, this provides a set of remote procedure calls (RPCs) for requesting test runs, monitoring systems under test (SUT), and so forth.

GENRIP is a kernel driver (presently for Linux only) that enables you to carry ethernet frames over generic low-speed/low-power serial radios, such as Microhards MHX series radios. It is intended to speed up the development cycle for those creating low-powered Embedded telemetry and SCADA devices, but may have other applications as well. Once installed, the serial radio simply appears as a network interface like this:

[root@lindev]# ./ifconfig gr0
gr0 Link encap:Generic Radio IP HWaddr 00:00:02:04:06:08
inet addr:192.168.15.1 Mask:255.255.255.0
UP RUNNING MTU:234 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:30
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

GENRIP was originally based upon Stuart Cheshires STRIP driver, which is part of the Mobile Computing Group at Stanford Universitys Mosquitonet project. It has been radically modified since.

GENRIP was ported to this application by Lawrence Wimble of Design On Demand, Inc. Design On Demand, Inc. maintains GENRIP and hopes that youll call them if you need help with an embedded project using GENRIP (or any embedded project for that matter).

GENRIP is released for Linux under the GPL. A port to FreeBSD is planned in the near future.

AustinSmoke GasTracker script will allow you to keep track of your gas mileage and have the results displayed in an easy to read website.

None of the data is harvested from anywhere on the web but is rather entered manually by the user and for the user.

Currently the program only supports the English system of miles and gallons. Future versions intend to include the metric system as well as conversions between the figures.

If the demand seems to exist, a future version will allow the user to import a CSV file (or something similar). This should satisfy any users who have historically kept up with such data with Excel and other spreadsheets.