Free windows tail 64bit software for linux

acpitail project shows in a tail-like way information off the battery-state, fan-states, temperatures, etc. of an ACPI capable system (mostly laptops).

Screendump:

laptop:/home/folkert/acpitail-0.1# ./acpitail -A 2
Mon Jun 18 15:28:45 2007
BAT0 remaining capacity: 99% (0 minutes)
Adapter AC: AC
temperature THM1: 50 (ok)
temperature THM0: 52 (ok)
Mon Jun 18 15:28:50 2007
temperature THM1: 49 (ok)
Mon Jun 18 15:28:55 2007
Adapter AC: batteries
Mon Jun 18 15:29:00 2007
temperature THM1: 48 (ok)
temperature THM0: 51 (ok)
Mon Jun 18 15:29:03 2007
Adapter AC: AC
Mon Jun 18 15:29:05 2007
temperature THM0: 50 (ok)

TinySID project is the smallest SID player available. Its most advantage lies in its unique HardSID support, that is:
- exact C64 PC cycle syncronizing
- multispeed tunes will use the same timing a real C64 does
- improved HardSID sample output (includes mixer)
- support for multiprocessor systems
- Previous versions required just 20kbyte disk space. This was however skipped due to 64bit support.
Main features:
- Multiplatform
- Native 32/64 bit windows support
- Runs on Unix/linux platform
- Playstation Portable (PSP) version available
- Also incorporated in rockbox for portable mp3 players
- Accurate playback on both hardsid and software emulation, includes multispeed tunes
- Digitized sample playback on both hardsid and software emulation
- 99% 6510 cpu emulation (still some bugs to fix)
- Fat 6581 SID emulation, including filters. Sounds different than other players!
Please note that TinySID has nothing to do with other projects such as SIDPlay. The 6510/6581 emulation is based on routines by Tammo Hinrichs (kb) and has been further developed.
Enhancements:
- This release added support for multi-speed tunes and digi-playback.
- Bugs in CPU emulation and endian neutral code were fixed.
- Speedups were achieved in the synth renderer.

Install Kernel interfaces with the Linux operating system by running a series of functions or groups of commands that automate the compiling or recompiling and installation process.
Install Kernel project consists of three groups of functions: building the kernel and moving files, checking dependencies, and editing the boot loader configuration file. Grouping all of the functions in these three groups makes maintaining and altering the script much easier.
Install Kernel can also be considered a program, because a program does checking and makes choices accordingly. A script is usually a file, which contains a certain number of commands with no logic in mind. Therefore, while ik is technically a script, it can also be called a program.
Dependency checks are to make sure the current system configuration and settings are properly setup before proceeding with the kernel build. There are seven dependency checks, they are: a root check, space check, link check, boot check, boot loader check, configuration check, and a module check.
First, the root check makes sure the user is a super user; which means they are capable of editing important system files only accessible to the root account. The space check makes sure there is at least 200 megabytes available.
The kernel source these days is around 150 megabytes just for the source code. When one compiles the kernel, it may increase the size to 50 megabytes or more. Therefore, ik
checks for at least 200MB available in order to successfully compile the kernel without running out of space. Next, it is not required, but it is standard to have a symbolic link of /usr/src/linux pointing to /usr/src/linux-x.y.z.
The fourth check makes sure the user has a /boot directory, this is where the Linux kernel files will be installed to. The fifth check determines the bootloader that will be used. There are two main boot loaders in Linux. LILO and GRUB are the two most popular for booting the operating system.
This check accurately finds whether the kernel was booted from either LILO or GRUB by checking which bootloader was used last. It then tells the rest of the script to edit the correct one accordingly. The sixth configuration check is to make sure users have created a proper kernel configuration file, which is used in the process of building the Linux kernel.
The final check is a module check, if modules are turned off, the script will determine this and alter the installation process to install with no module support. The main idea behind the depdency checks is to make sure the user cannot damage his or her system if they do not do something right.
The installation process also contains seven functions. The installation process is usually several commands. However, because of the differences that can occur in a users configuration file, each part of the building process must be checked and the building process may need to be altered.
The first function makes sure the dependencies are setup correctly for all files in the kernel source tree. The second function deletes stale object files and or old kernel files. Next, the third function is the kernel build function; this function runs a command to build the Linux kernel. Next, functions four and five make and install modules if the user had specified module support in his or her kernel configuration file.
The sixth function moves the Linux kernel and its System dependency map to the boot partition. The last function of the build process sets up module dependencies for the new kernel if modules were defined. The installation process also includes a small error check for each part of the kernel build process.
If any part of the kernel build process fails; the script will abort, not modifying any boot loader configuration files. This is important; because if it did not abort, it may alter the boot loader configuration files, thus rendering the system unbootable. It is important to support every Linux configuration possible because of the wide use of this script.
The boot loader configuration and setup process is probably the most important aspect of installing a new kernel. An improper boot loader configuration may leave one with system that does not boot; or simply does not boot the new kernel.
It is also important, as some systems may have two or more boot loaders installed. There are four functions defined for this process. The first function uses the boot loader, which was defined during the configuration checks. The second function defines where the LILO or GRUB configuration files are located.
Next, depending on which boot loader is found, either LILO or GRUB configuration files are edited automatically by sed. Sed is a stream editor, which edits a file with no user intervention. If user intervention were required, the user would have to be present between certain parts of the kernel installation. With ik, it makes efficient use of a users time because only one command needs to be entered to complete the entire installation and setup process.
Install Kernel is a useful tool for those who are new to Linux, rebuild their kernel often, or value their time. It reduces the commands for installing the kernel from about thirteen to one. Users new to Linux may find this attractive.
This is because the entire process is automated; and if something is not correct, in most cases ik will notify the user what is incorrect, and how to fix the error. On the other side, for experienced users who do not wish to spend valuable time installing a new kernel, this is also very handy. Install Kernel is efficient by requiring no user intervention and reducing time spent on kernel installs, and effective by giving new to Linux the option for an easy kernel upgrade.
Enhancements:
- Updated to work with the newer version of coreutils for head and tail.
- The MAKE_JOBS directive has been removed in favor of make -j2 to prevent make from spawning hundreds of jobs if /proc/cpuinfo did not exist.

Wide Area Link Emulator enables you to set and test various parameters of a WAN access link (also known as a bottleneck link) before testing on a fully-functional network.

Any ISP has a high bandwidth LAN (of the order of tens of Mbps, e.g. Ethernet) and a WAN access link with relatively low speeds (of the order of a few Kbps to a few Mbps). To be able to evaluate the ISPs performance, actual tests will have to be conducted on a live, fully functional network. This would imply enabling certain features in communication equipment which could be detrimental to the proper functioning of a commissioned network. To address such a problem of being able to characterize/quantify the network operation in terms of its performance with respect to various parameters, a test-bed emulating the ISPs connectivity to the Internet would be an ideal solution.

An important factor in setting up such a test-bed, is emulating the WAN Access Link. Using complex hardware is costly. Such a link can however be easily implemented by emulating the scenario on popular physical technology such as Ethernet. By changing the TCP/IP stack on a Personal Computer, the rate at which packets are injected into the network can be controlled and other necessary features can easily be added.

WALE was implemented in 2 phases and the first version can emulated bandwidths up to 8Mbps and uses FIFO queues with drop-tail.

WALE v2 can emulate bandwidths of up to 80Mbps(a 10-fold improvement over version 1) due to the stripped down version of Micro-second resolution timer being used in the Linux kernel. WALE also implements differentiated services are recommended by IETF. A hash-based packet classifier is used to classify packets into one of 3 queues (Expedited Forwarding, Assured Forwarding and Best Effort). A simple priority scheduling has been implemented between the queues.

Version 2 has been implemented in the Generic Device Layer of the Linux Kernel. The kernel version is 2.2.19. WALE2 kernel patch can be downloaded here. An ncurses based front end has been implemented for setting and viewing various parameters of the bottleneck link.

Bandwidth Monitor NG is a small and simple console-based live bandwidth monitor.
I have sucessfully tested on (if you have any other sucessfull or unsucessfull, please mail me):
Linux 2.4, Linux 2.6
FreeBSD 4.8, 5.3
MacOS X 10.1, 10.2, 10.3
Solaris 10 64bit x86
SunOS 5.9 sparc Solaris 9
OpenBSD 3.4, 3.6
NetBSD 1.6.1, 2.0
IRIX64 6.5
Main features:
- supports /proc/net/dev, netstat, getifaddr, sysctl, kstat and libstatgrab
- unlimited number of interfaces supported
- interfaces are added or removed dynamically from list
- white-/blacklist of interfaces
- output of KB/s, Kb/s, packets, errors, average, max and total sum
- output in curses, plain console, CSV or HTML
- configfile
Enhancements:
- Changes in this release include curses2 output (a nice bar chart), disk input for BSD, Mac OS X, Linux, and Solaris, Win32 network bandwidth support, use of autotools, and lots of fixes.

Test::Tail::Multi is a Perl module to execute code, monitor dynamic file contents.

SYNOPSIS

use Test::Tail::Multi files => [qw(file1 file2)] tests=>2;
# Can add files dynamically as well
add_file(file3, "decided to add file3 too");

# Execute a command and check against output
contents_like {system(my_command -my_args")} # Note no trailing comma!
qr/expected value/,
"got the expected output");

# if code to execute is undef, check against previously captured new content
contents_unlike undef, # trailing command REQUIRED
qr/unexpected text/,
"unexpected stuff not found in same text");

# Shorten the delay to 1 second.
delay(1, "Now a 1 second delay");
contents_like(sub {system(fast_command)}, # trailing comma in parens
qr/expected/,
"this command runs faster");

Test::Tail::Multi allows you to create tests or test classes that permit you to monitor the contents of one or more files a la < tail -f > using the nice File::Tail module. You can execute arbitrary code and then run tests versus the new content in the files.
If you choose, you can run multiple tests against the same content by passing undef as the code to be executed; Test::Tail::Multi will then reuse the contents it last extracted.

You can also adjust the delay time to be used to allow the code you called to "settle down" before checking the tails.

Test::Tail::Multi comes in handy for those testing jobs that require you to monitor several files at once to see whats happening in each one.

Tail server allows you to export the output of a "tail -f" command of a log file to a TCP port, allowing it to be viewed remotely with telnet. Tail Server provides a regular expression filter to include or exclude output view.
In several circumstances the need to access on remote time-varying log file leads to write some simple scripts.
These files generated by applications like syslog, http, news, etc. are often located on different machines.
System Administrator usually logon on remote system then type:
# tail -f filename
Tail Server offers the possibliy to map on Tcp/Ip port the output of "# tail -f filename" without (each time) logging on remote systems.
Also offers output regular expressions filter in order to include or exclude strings.
Enhancements:
- Server Log File has been implemented.