Free july software for linux

JikesTM is a compiler that translates JavaTM source files as defined in The Java Language Specification into the bytecoded instruction set and binary format defined in The Java Virtual Machine Specification.

You may wonder why the world needs another Java compiler, considering that Sun provides javac free with its SDK. Jikes has five advantages that make it a valuable contribution to the Java community:

* Open source. Jikes is OSI Certified Open Source Software. OSI Certified is a certification mark of the Open Source Initiative.
* Strictly Java compatible. Jikes strives to adhere to both The Java Language Specification and The Java Virtual Machine Specification as tightly as possible, and does not support subsets, supersets, or other variations of the language. The FAQ describes some of the side effects of this strict language conformance.
* High performance. Jikes is a high performance compiler, making it ideal for use with larger projects.
* Dependency analysis. Jikes performs a dependency analysis on your code that provides two very useful features: Incremental builds and makefile generation.
* Constructive Assistance. Jikes strives to help the programmer write better code in two key ways. Jikes has always strived to provide clear error and warning text to assist the programmer in understanding problems, and now with release 1.19 Jikes helps point out common programming mistakes as documented in Effective Java.

Abridged from a FAQ entry which was adapted from some material by Lou Grinzo for an article he wrote.

The fact that Jikes is a high-performance, highly compatible Java compiler that can be used on almost any computing platform makes it an interesting program and worth investigating for almost any Java programmer. But Jikes is also notable because it lies at the center of two events: the adoption of open source philosophy and practice by large corporations, and the continued growth of Java for Linux.

Its worth pointing out that Jikes is not, and is not intended to be, a complete development environment -- it is simply a command line compiler. It should not be considered a replacement for more complete tools, such as Source Navigator or IBMs VisualAge for Java which provide sophisticated graphical IDEs (Integrated Development Environments).

The Jikes compiler was released in binary form in April 1997 on the IBM alphaWorks site. Jikes for Linux was released on 15 July 1998. The response was overwhelming -- Jikes had more downloads in the three months after the announcement than in the fifteen months before the announcement.

Release of Jikes for Linux was soon followed by requests to open up the source. Many notes and comments from users suggested this would be a good idea. The source was released under a liberal license in December 1998 to make a very visible demonstration of IBMs commitment to open standards and to Java Technology, to make Jikes more reliable and accessible, to encourage more widespread use of Java Technology, to encourage standardization of Java Technology, and to gain some experience actually running an open source project. This marked the start of one of IBMs first efforts in the open source arena.

The original alphaWorks version of Jikes was written by Philippe Charles and Dave Shields of the IBM T. J. Watson Research Center. Since the release of the source they have continued to work on the compiler as contributors; however recently have officially been moved on to other projects within IBM. Today there are no IBMers who work on Jikes as part of their job description. Jikes survives today soley based on the free time contributions of members of the open source community.

The source code is available under IBMs Public License, which has been approved by the OSI (Open Source Initiative) as a fully certified open source license. The project provides access to the complete CVS development tree, which includes not only Jikes, but also the source for the Jacks Test Suite and the Jikes Parser Generator used to build Jikes. Jikes is included in many Open Source Operating Systems. The Jacks Test Suite is a replacement for the Jikestst package.

Ice Hockey Manager is a hockey simulator which has the ultimate goal of creating a game that offers the most realistic simulation experience possible. Our focus is more on substance than style.
While we want the game to be intuitive, we arent looking to compete with the flashy 3D graphics you might see in games from EA or Sega. Theyve pretty much cornered the market when it comes to pretty graphics.
Were more interested in games that challenge your mind and not your hand-eye coordination. We plan to take hockey simulators (and perhaps sports simulators in general) to places theyve never gone before, The way we see it, the possibilities are limitless, much like real life hockey.
While IHM may not have photorealistic facial features for every player model in the NHL we do strive to create a game that really does make you feel like you are at the helm of your own hockey franchise.
We first started developing IHM in late 2001 and the development team consisted of two members, Bernhard von Gunten and Arik Dasen. The first real release of the game was version 0.1.1 in January of 2002. The game was playable but still very basic, more intended as a framework for future development. In July of 2002, version 0.1.2 was released with many updates to the game but after this release the project essentially went on hiatus until September/October of 2004.
Up until that time the project hadnt garnered much interest from the open source community, either the project was too localized to Swiss-style hockey or it perhaps just didnt get the exposure needed to get people to jump onboard, whatever the reason, IHM seemed to be more of a labor of love than a project that perpetuated itself. Fortunately, in October 2004, development kicked back into gear and all sorts of new and exciting features started to take shape. Some of these features include computer AI, multiplayer-support, trading/transfers, sponsoring/finances, full season/playoffs simulation, etc.
And the IHM team is currently working towards version 0.3, which has been dubbed a "Preview Release" to demonstrate a fully-operational playable game. Will this Preview Release set any kind of standard as far as hockey simulators are concerned? No, not yet. In fact, many elements within the game are still rather simplified, such as in-game simulation (which will begin development post-0.2), but we hope the Preview Release will compel other open source developers to help out with the project as there is still a lot to be done before IHM can be considered a complete game.
This website is intended to both introduce you to the game as well as to encourage you to participate and/or contribute to this project in some way. Whether you are a Java developer, a graphic artist, a beta tester, or something else entirely, we want to hear from you. IHM cant build itself, and while we have invested many hours into the games development we still have our limitations as to what we can achieve, both in time and resources. So if you think you can help out in some way, please let us know. Ideally, you should be a fan of hockey, but thats about the only prerequisite.
Main features:
- Game controller, based on a game calendar.
- Multiuser framework
- League framework (Swiss style leagues implemented, including playoffs and relegations).
- Teams, with statistics and informations.
- Players with attributes, statistics, contracts and informations.
- Simulated matches with generated plays and "radio" output.
- Training
- Injuries
- Contracts framework
- Sponsoring framework, based on contracts
- Financial framework
- Real Impacts (on teams & players)
- Transfers (Swiss style)
- Infrastructure framework (Arena implemented)
- Prospects
- Assistants
- and more ...
Technical stuff:
- Written in 100% pure Java
- Running under Linux and Windows and every other Java 1.5 platform
- Swing GUI
- More than 200 java classes
- More than 30000 lines of code

Americas Army is one of the five most popular action games played online. It provides players with the most authentic military experience available, from exploring the development of Soldiers in individual and collective training to their deployment in simulated missions in the War on Terror.
Americas Army: Special Forces is the follow-up to Americas Army: Operations, which was released on July 4, 2002.
In Americas Army: Special Forces, players attempt to earn Green Beret status by completing individual and collective training missions drawn from the Special Forces Assignment and Selection (SFAS) process.
Players who complete the SFAS process have the opportunity to take on elite Special Forces roles and are qualified to play in multiplayer missions with units ranging from the elite 82d Airborne Division to the 75th Ranger Regiment.
Includes the complete game Americas Army: Operations.
Main features:
- Authentic U.S. Army experience Realistic depiction of the values, units, equipment and career opportunities that make the Army the worlds premier land force continually updated to incorporate new occupations, units, technologies and adventures.
- Realistic roles Including Weapons Specialist (18B), Intelligence (18F), Engineer (18C), Communications (18E) and Combat Medic (18D).
- Challenging Green Beret training Complete training missions drawn from the SFAS process at Fort Bragg. Successfully complete SFAS and advance to Special Forces Qualification Course (Q-Course) missions to explore new Special Forces roles.
- Intense Special Forces action Intense Special Forces action Experience multiplayer missions in simulated combat environments. Take part in missions that span the capabilities of a Special Forces detachment, including unconventional warfare, direct action, surveillance and reconnaissance and Combat Search and Rescue.
- Detailed Special Forces equipment and military hardware Building on the equipment available in Americas Army: Operations, Americas Army: Special Forces adds the M4 Carbine featuring the Picatinny rail mod system for attaching laser-aiming devices and sighting systems; the MP5SD6 Remington 870 shotgun for forced entry; the AT4, a shoulder-fired anti-tank rocket and the BDM, a shoulder-fired bunker demolition munition.
- Accurate Soldier behavior Players are bound by the laws of land warfare, Army values (honor, duty and integrity) and realistic rules of engagement as they navigate challenges in teamwork-based multiplayer force vs. force operations. Mission accomplishment standings are evaluated based on team effort and adherence to a set of values and norms of conduct.

PieSpy is an IRC bot that monitors a set of IRC channels. It uses a simple set of heuristic methods to infer relationships between pairs of users. These inferrences allow PieSpy to build a mathematical model of a social network for any channel. These social networks can be drawn and used to create animations of evolving social networks.
PieSpy has also been used to visualize Shakespearean social networks.This page got slashdotted on 11 March 2004, with the site getting 250,000 hits per hour. Thanks to Notnet for making sure it all stayed alive!
PieSpy was presented at the Information Visualization conference (IV04) in July 2004. Read the full paper online. It has also appeared in Computer Weekly, ct magazine, and I was interviewed live on BBC Radio Kent.
Enhancements:
- Now tracks nickname changes. Generates images five times faster. Removes formatting and colors from messages. The source code has been refactored to make it easy to add new InferenceHeuristics, which are used to work out who is talking to whom - if you create any good ones, let me know! The config file lets you apply different weightings to each InferenceHeuristic.

Plan 9 From User Space is a port of the bulk of the Plan 9 software build environment to Unix.
While the libraries make an attempt to play nice with the rest of the system (by using the Unix rules for printf verbs and Unix system headers, for example), this port tries to reproduce the Plan 9 build environment as faithfully as possible, providing u.h and libc.h, and blithely redefining tokens such as open, dup, and accept in order to provide implementations that better mimic the Plan 9 semantics.
The result is a more complicated and less Unix-friendly environment, but Plan 9 programs can typically be compiled with little or no changes.
Most obviously, plan9port derives from Plan 9 from Bell Labs and would not exist without the work of the Plan 9 team over the past many years.
Rob Pike suggested the original X11 port of libdraw years ago, as part of drawterm, and strongly encouraged the Mac OS X work. He has also been a consistent source of good ideas to hide the ugliness of modern Unix.
William Josephson handled troff(1) (with Taj Khattra) and many of the supporting programs. He also inspired the thread library clean-up and has ported a handful of applications.
Andrey Mirtchovski and Axel Belinfante have done significant work dealing with X11 corner cases and fine-tuning rio(1). Axel never tires of finding bugs in the SunOS port.
Latchesar Ionkov has contributed many fixes to tricky bugs, and got factotum(4) up and running.
Many other people have provided help, ported programs, written bug reports, sent useful patches, and gotten plan9port running on new systems.
Bigelow & Holmes, Inc. created the screen fonts in the luc, lucm, lucsans, and pelm directories and granted permission to redistribute them with plan9port.
Enhancements:
- A FUSE-related bug was fixed. See http://lists.cse.psu.edu/archives/9fans/2006-July/048531.html

Hackystat is a framework for the automated collection and analysis of software engineering product and process data.
Hackystat uses sensors to unobtrusively collect data from development environment tools; there is no chronic overhead on developers to collect product and process data. Hackystat does not tie you to a particular tool, environment, process, or application.
Hackystat project is intended to provide in-process project management support.
Hackystat is in its sixth major architectural release family. The first architectural release family, called the "Spike Solution", was used to explore the feasibility of the approach and to evaluate various component technologies (including JATO, XSL, Ant, JUnit/HttpUnit, Tomcat, Cocoon, and SOAP). Work on this Spike Solution architecture lasted eight months, from May to December, 2001.
In December 2001, we began a major re-implementation of the system in order to provide architectural support for design discoveries made with the Spike Solution. This second architectural release family is called the "Framework Architecture", because it implements package and class-level patterns that facilitate extension of the system via inheritance and composition of existing classes. Unfortunately, the Framework architecture required modification of the hackystat source code to implement new sensors and analysis, and only a single configuration of analyses and sensors can be supported in this architecture.
In November, 2002, we began work on the "SDK" (or "kernelized") architecture release family. This third architectural family decomposes the system into two layers. The first layer is a kernel system which implements the core facilities for data definition, storage, transmission and user interface.
Developers build an actual Hackystat installation by combining the framework with a second layer: a set of plug-in extension modules that define the specific sensor data types, tool sensors, and analyses required to support their development procedures. In the SDK architecture, developers can implement new sensors and analyses without modifying the underlying kernel code, and multiple Hackystat installations can be built with different configurations of analyses and sensors.
In June, 2003, we performed a package restructuring that facilitates the development of third layer, or "application" layer systems. This is the fourth architectural release family, called the "Three Layer" architecture.
After only a month of application layer development, we realized that the build process we developed for the second release family would be woefully inadequate to support the three layer architecture, in which multiple components would be combined into a configuration for release.
So, in August, 2003, we released the fifth architectural release family, called the "Component Architecture", along with extensive new build support including the hackydev web site with daily integration builds.
In July, 2004, we released the sixth architectural family, which provides services to support a "telemetry" based approach to software project monitoring and control. This includes various caching mechanisms, as well as the hackyTelemetry package that includes a telemetry specification language and associated APIs. In this architecture, telemetry support becomes a "low level" feature of the system.
Enhancements:
- A new sensor for IntelliJ Idea, enhancements to the Visual Studio sensor, improved support for test driven development inference, and many bugfixes.

Getopt::Clade is a Perl module with command-Line Argument Declaration Engine.

This module is a placeholder for the real Getopt::Clade module. The module was supposed to be released by July 2005, to support the book "Perl Best Practices". Unfortunately, due to a series of family medical crises, the release of the module has been delayed, probably to early September 2005.

I sincerely apologize for any inconvenience this delay may cause. If you are looking for an alternative Getopt:: module, you may like to consider Getopt::Declare or Getopt::Euclid.

FTwall is short for Fast Track traffic Firewall, a P2P traffic filtering script, for Kazaa blocking.
Ftwall-2 is an updated version of the original ftwall-1 software which adds new P2p protocols to the set it can control.
Ftwall-2 is an add-on for linux firewalls that allows the control of "Fast Track" peer-to-peer traffic (such as is used by "Kazaa" and its derivatives), WinMX and others using the OpenNAP protocol.
It is designed to block network traffic from P2P client applications running in the "home" (or "green") network from making access to any peers on the public internet. It is designed primarily for use in networks where the security reigme allows "open access" for outbound connections and "tightly limited" access for inbound ones. Ftwall-2 can be used in networks like this to prevent outbound P2P access from the supported protocols, hence restricting illegal file downloads and uploads.
A Fast track "home network" client that establishes an "outbound" connection is (worryingly) immediately available to accept inbound connections through the established TCP/IP socket - even if the gateway firewall blocks all in-bound connections via "normal" TCP/IP and UDP mechanisms. This is a kind of limited "tunnelling" and gives rise to a number of concerns. Other P2P applications and protocols present similar security challenges. Ftwall solves this (and other) problems for the protocols it understands.
Version 1 of ftwall controlled the Fast Track protocol only (Kazaa et al).
Version 2 of ftwall (the version discussed on this page) adds logic to allow blocking of traffic from WinMX and OpenNap clients using a mechanism based on DNS name wildcards. One simple example is the control of WinMXs native protocol which can be blocked by preventing access to IP addresses resolved from any domain name that ends "winmx.com". OpenNAP is similarly controlled using DNS wildcards to "train" ftwall. See the man page (etc) for these new features by following the links at the bottom of the page.
FTwall-2 runs on Linux-based firewalls using kernel 2.4 (tested with 2.4.20) or later and iptables (test with version 1.2.6). This combination of version numbers is the current set employed by RedHat 8.0 - which is the system on which the software has been developed. The software has also been tested briefly on RedHat 9 and Fedora - but I am awaiting more in-depth news of these and other Linux distributions.
FTwall-2 runs well on the "ipcop" firewall, version 1.3.0 (GPL) with the QUEUE target and string match modules added manually. I believe that it will similarly run on Smoothwall 2 (GPL) although I have not tested this. It will NOT run on Smoothwall 1.0 since this is an "ipchains" based firewall, not an "iptables" one.
FTwall-2 has been tested with the following P2P client applications:
Kazaa 2.1.1, 2.5-beta2, 2.5.1
Kazaa Lite 2.0.2, K++ 2.4.3
iMesh 4.1 build 132, 4.2 build 138
Grokster 1.7
WinMX 3.31
Version restrictions:
- Ftwall requires Linux kernel version 2.4, equipped with "iptables" and the "QUEUE" target. The "ip_string" match module of iptables is desirable, but not required.
- Ftwall works with the "current" version of the Fast track, WinMX and OpenNAP network protocols at the time of writing (July 2004). It is possible that it will need to be re-worked if the protocols are changed in future.
- Ftwall does not block the "SOCKS PROXY" connection option of FastTrack. For a complete lock-down, the firewall must block this style of traffic.