This package is a port of TAMU's extract program from NetLogger to look
at flow data instead of netlogger data. Blame Larry for it's faults, not
TAMU. Blame me for the FreeBSD port, not Larry :-)
If you don't already have a good guess what this program does and what
data it is looking for, the odds are that it isn't going to be of much
help to you. This program only works on Cisco flow data as captured
with Mark Fullmer's flowtools package. If you don't have that, get that
first, then look at this program.
In order for this to compile you will need flowtools from Mark
Fullmer's (net-mgmt/flow-tools port).
Nstreams is a program which analyzes the streams that occur on a network. It
displays which streams are generated by the users between several networks,
and between the networks and the outside. It can optionally generate the
ipchains or ipfw rules that will match these streams, thus only allowing what
is required for the users, and nothing more.
Nstreams can parse the tcpdump output, or the files generated with the -w
option of tcpdump. It can also directly sniff the data that occurs on the
network.
This product was designed by HSC and coded by Renaud Deraison
(deraison@cvs.nessus.org), author of the Nessus software (www.nessus.org). It
is available for free and under GNU license.
This package provides a suite of modules for managing NetApp's NAS
devices, commonly referred to as "filers".
This is the first public release of my NetApp Perl API, and although I
consider the code to be very stable, the API should be considered
experimental. The convention I will be following regarding
non-compatible API changes is as follows. I'm using a
major.minor.subminor release naming convention, and I will promise to
NOT make non-backwards compatible changes between subminor releases.
However, in order to allow the API to evolve, it is entirely possible
that non-backwards compatible changes will be made between minor
releases. IOW, the major.minor release numbers can be considered an
API version. Any changes to 1.1.0, 1.1.2, etc. must be backwards
compatible with the previous 1.1.* releases.
There is no guarantee that 1.2.0 will be 100% backwards compatible,
although such changes will be made only when justified. The author
does not believe in infinite backwards compatibility.
Litecoin is a peer-to-peer Internet currency that enables instant payments to
anyone in the world. It is based on the Bitcoin protocol but differs from
Bitcoin in that it can be efficiently mined with consumer-grade hardware.
Litecoin provides faster transaction confirmations (2.5 minutes on average) and
uses memory-hard, scrypt-based mining proof-of-work algorithm to target the
regular computers and GPUs most people already have. The Litecoin network is
scheduled to produce 84 million currency units.
One of the aims of Litecoin was to provide a mining algorithm that could run at
the same time, on the same hardware used to mine bitcoins. With the rise of
specialized ASICs for Bitcoin, Litecoin continues to satisfy these goals. It is
unlikely for ASIC mining to be developed for Litecoin until the currency is
widely used.
microdc is a command-line based Direct Connect client written in C by Oskar
Liljeblad and designed to build and run on modern POSIX compatible systems.
It uses GNU Readline library for user interaction. Despite the command-line
user interface, microdc is quite user friendly and simple to use.
microdc2 is a future improvement (fork) of the microdc based on Oskar's code
version 0.11.0. After version 0.12.0 the project was renamed to microdc2 on
Oskar's request.
Features of microdc2 include:
- Nearly full support of the original Direct Connect protocol
- GNU Readline support for command line editing and history
- Sensible tab-completion of commands, user names, local files, remote
files, speed names, and connection names
- One process per connection for optimal transfer rates
- Small memory footprint
The nettest and nettestd commands invoke client and server
programs that are used for timing data throughput of vari-
ous methods of interprocess communication. For TCP and
OSI connections, the nettest program establishes a connec-
tion with the nettestd program, and then it does count
writes of size bytes, followed by count reads of size
bytes. For UDP, the nettest program performs only writes;
reads are not performed. The nettestd program, if used
with UDP connections, reads the data packets and prints a
message for each data packet it receives. The number and
size of the reads and writes may not correlate with the
number and size of the actual data packets that are trans-
ferred; it depends on the protocol that is chosen. If you
append an optional k (or K) to the size, count, or bufsize
value, the number specified is multiplied by 1024.
OpenNX is an open source drop in replacement for NoMachine's NX client. It is
compatible to the original client in that it uses the same syntax for the
session configuration files (.nxs files). OpenNX is distributed under the GNU
Lesser Public License v2.1. OpenNX is written in C++ and uses the excellent
wxWidgets toolkit. Compared to the original client, it also adds some
additional features which improve usability:
- Ability to use the OpenSC framework to enable SmartCard based
authentication for the initial SSH connection.
- Ability to use a variety of different proxy types.
- Ability to fetch session configuration files via http (read only)
- Ability to disable configuration controls by providing a read only
configuration file.
- Dynamic use of libsmbclient, libcups, libopensc and pulseaudio (no static
dependencies).
- Uses libjpeg-turbo for speed improvement (if available).
Net::Frame is a fork of Net::Packet. The goal here was to greatly
simplify the use of the frame crafting framework. Net::Packet does
many things undercover, and it was difficult to document all the thingies.
Also, Net::Packet may suffer from unease of use, because frames were
assembled using layers stored in L2, L3, L4 and L7 attributes. Net::Frame
removes all this, and is splitted in different modules, for those who only
want to use part of the framework, and not whole framework.
Finally, anyone can create a layer, and put it on his CPAN space, because
of the modularity Net::Frame offers. For an example,
see Net::Frame::Layer::ICMPv4 on my CPAN space.
Net::Google::SafeBrowsing2 implements the Google Safe Browsing
v2 API.
The library passes most of the unit tests listed in the API
documentation. See the documentation
(http://code.google.com/apis/safebrowsing/developers_guide_v2.html)
for more details about the failed tests.
The Google Safe Browsing database must be stored and managed locally.
Net::Google::SafeBrowsing2::Sqlite uses Sqlite as the storage back-end,
Net::Google::SafeBrowsing2::MySQL uses MySQL. Other storage mechanisms
(databases, memory, etc.) can be added and used transparently with this module.
You may want to look at "Google Safe Browsing v2: Implementation Notes"
(http://www.zscaler.com/research/Google%20Safe%20Browsing%20v2%20API.pdf),
a collection of notes and real-world numbers about the API. This is intended
for people who want to learn more about the API, whether as a user or to
make their own implementation.
This module handles the SOAP protocol. The first implementation is SOAP1.1
(http://www.w3.org/TR/2000/NOTE-SOAP-20000508/), which is still most often
used. The SOAP1.2 definition (http://www.w3.org/TR/soap12/) is quite
different; this module tries to define a sufficiently abstract interface to
hide the protocol differences.
Be aware that there are three kinds of SOAP:
1. Document style (literal) SOAP, where there is a WSDL file which explicitly
types all out-going and incoming messages. Very easy to use.
2. RPC style SOAP literal. The WSDL file is not explicit about the content of
the messages, but all messages must be schema defined types.
3. RPC style SOAP encoded. The sent data is nowhere described formally. The data
is transported in some ad-hoc way.