Free lead to software for linux

Enblend project is a postprocessing tool for creating panoramic images. After you align image features using a program like Hugin, there are often photometric problems that lead to ugly seams in the final composite.
Enblend blends away these seams using a multiresolution spline. This technique gives good results on both low spatial frequency objects (sky and clouds) and high spatial frequency objects (trees and houses).
Enhancements:
- This release features faster image processing computations and a new seam line optimization algorithm.
- Masks can now be saved and loaded from files, color blending can be done with the CIECAM02 color appearance model, and the graphics processor can be leveraged for higher performance.

RefDbg project is a GObject reference count debugger GObject is part of the glib library (not to be confused with glibc) which forms the basis of GTK+ (the Gimp ToolKit), Gnome, GStreamer and many other projects. The GObject library adds object oriented stuff to C which by itself lacks object oriented features.

Since C lacks garbage collection, a reference counting system is used. Each object has a count of how many other references (pointers) there are to it. Reference count bugs can be very hard to track down and can lead to crashes and memory leaks. Refdbg is a tool that can be used interactively with GDB to log, display and break on reference count activity, thereby making this task easier.

Local Area Security is a research group focused on information security related subjects. We are most known for L.A.S. Linux. Our live-CD security toolkit.

Local Area Security is a project that was started in 2002 to research information security related topics. During that time there was no real live-CD toolkit focused on information security.

So Jascha, the project founder built one from a stripped down version of Knoppix called Model-K. Both of which were built from Debian Linux.

Up until version 0.4 L.A.S. Linux was command line only. Which made it limited to some of the tools it could contain since many require a GUI. Or at least for many it is preferable to have one. So FluxBox was added as the desktop since it is light weight and very feature filled.

It was during this time that Jascha came up with the idea of keeping the size of L.A.S. as small as possible, which lead to a target maximum size of 180MBs. The size of the original mini-CDs that were available at the time. This forced the selection of tools and features to be weighed heavily since unlike other live-CDs that throw in everything including the kitchen sink. L.A.S. was designed from the ground up to be a tool not a all-inclusive grab bag of applications.

As well as many advances for live-CDs came about, such as to-ram that allows booting a live-CD into the physical RAM of a computer. Which by chance L.A.S. was perfectly cut out for. With as little as 256MB of RAM people could boot L.A.S. and then free up their CD-ROMs for burring etc.

For forensics this was a big plus, along with many other uses. Plus L.A.S. ran very fast in RAM which helped with running Nessus, Nmap, or other tools. When compared to full size (700MB) CDs which would require 1GB of RAM to use the to-ram option, it was really no contest.

Icecast is a streaming media server which currently supports Ogg Vorbis and MP3 audio streams.
Icecast can be used to create an Internet radio station or a privately running jukebox and many things in between.
It is very versatile in that new formats can be added relatively easily, and it supports open standards for communication and interaction.
Enhancements:
New features:
- new tag < logsize > in < logging > state the trigger size (in KB) for cycling the log files.
- new tag < logarchive > in < logging > enable (1) if you want to use a timestamp for an extension when cycling logs.
Fixes:
- Handling of certain shoutcast source clients is fixed, this typically affected NSV source clients
- A race in source shutdown when listeners are authenticated could lead to server crash
- An audio glitch was possible in playback of vorbis streams when a new logical stream started (eg metadata update).
- stats speedup. Processing large numbers of stats was slow. Typically only seen when using lots of streams on the same server.
- 404 responses were being sent back in some places, now 403 is sent back.
- Auth URL now handles the authentication to scripts better.
- The order in which username/password are selected is
- 1. url is http://user:pass@host:port/....
- 2. < param name="username" > and < param name="password" >
- 3. with listener_add/remove, listener supplied username/password is used.
- A streams intro file can now be changed, using HUP, on active streams.
- mount without a name crashed the server
- Various documentation updates

JProfiler is an award-winning all-in-one Java profiler. JProfilers intuitive GUI helps you find performance bottlenecks, pin down memory leaks and resolve threading issues.
Even though JProfiler has a powerful feature set, its a Java profiler that is extremely easy to use! JProfilers user interface provides a unified view on the profiled application and puts all the information you need right at your fingertips with its intuitive hierarchy of views.
Configure your application for profiling
When starting up JProfiler, the start center is brought up. Here you can manage and start your profiling sessions. To configure your application for profiling, change to the "New session" tab and click on the New session button. Enter the required information into the session config dialog as described below and select Ok to start profiling. Thats all it takes. Note the Help button which appears on all of JProfilers dialogs displays a context sensitive explanation of all features.
While the configuration dialog displays numerous options that you will not want to miss after becoming familiar with JProfiler, entering the basic pieces of information is really very simple:
1. Enter a name for your session.
2. Enter the name of your main class.
3. Enter your class path.
4. Press Ok.
Before profiling is actually started, the profiling settings dialog is displayed where you can select the focus for your profiling run. Although profiling produces an overhead when running your application, you can minimize it by choosing a setting for which JProfiler only records information that is interesting for you.
If you want to fine-tune your profiling settings, the [Edit] button brings up a dialog with all available configuration options for profiling.
Observe classes and allocations
To find out what is going on the heap in terms of objects and classes, turn to the classes monitor. It gives you continuous updates and lets you set marks to observe changes over time. To see references, allocations and object data for your selection, you can take a snapshot by clicking on the camera in JProfilers toolbar.
If you want to know where your objects are allocated, you can go to the allocation monitor. Here, you can inspect the call tree and find out what method calls have caused the allocation of a selected class or package. Just like in the allocation monitor, you can display this data for live and garbage collected objects.
An cumulated overview on which methods are responsible for allocations is given by the allocation hot spots view. Each hot spot can be expanded and the backtraces that lead to the invocation of the hot spot are displayed. You can also mark the current values and view the differences in allocations over time.
Find memory leaks
JProfilers heap walker works like a browser: it displays a current set of objects that can be changed by adding selection steps with the [Use selected] button. You can inspect the current object set in the four views of the heap walker.
In the classes view, you can select one or several classes and add a selection step. The new object set will contain only the selected instances. This is often the first thing you want to do after taking a snapshot. You can perform this step automatically by invoking the heap walker from the classes monitor.
The allocations view of the heap walker shows the allocation tree and the allocation hot spot list of the current object set. You can add a selection step for one or multiple allocation spots or hot spots. The new object set will then be restricted to the selected instances only.
When youre looking for the cause of a memory leak, the reference view is the most important view in JProfiler. Here, you can find out why an object has not been garbage collected. Use the "Show path to GC root" function to show where the JVM hangs on to the selected instance.
Not only is the heap walker your first stop for finding memory leaks, it also makes for an excellent debugging facility. In the data view, you can inspect instances, arrays and classes in the current object set and navigate along references. There are many situations where the usual debugging approach will fail and JProfiler will help you find out.
Zoom in on performance bottlenecks
Controlling your applications performance may be driven by quality of service constraints or by general quality assurance, JProfilers CPU views lend themselves naturally to both approaches.
To record CPU data, you switch to the CPU section and click on the recording button in JProfilers tool bar. The first view in the CPU section shows the invocation tree, cumulated for all threads. To find performance related problem spots, just follow the big percentages when opening the tree nodes. Also, the absolute times and the number of invocations that are displayed for each node can help you in getting a feeling for the situation. Once you become familiar with JProfiler, you may want to customize this view to best fit your personal preferences.
The invocation tree is a top-down view on the method calls of your application. This viewpoint is most useful when you experience an actual performance bottleneck in your application. If you want to improve overall performance, a bottom-up view may be more applicable.
This kind of view - called hot spots view - shows the methods where most of the time is spent. By opening these nodes you get backtraces which show the various invocation paths together with the percentages of their contributions. Note that by default, method calls within Java core classes are not shown separately - each of your library calls is treated as opaque. You can change this behavior by deactivating the corresponding filter sets.
The method graph combines both viewpoints. Incoming and outgoing method calls are presented in the same way. For a number of situations, the method graph can give you more insight than the invocation tree and the hot spots view. The best strategy is to use the invocation and hot spots views first and switch to the method graph for detailed analysis.
Solve thread-related problems
Threads can be exceptionally difficult to debug, especially if you dont have sufficient information on the actual sequence and status of the threads in your application. JProfilers thread views provide you with exactly this knowledge.
The thread history view shows a continuous update of the lifelines of all threads on the horizontal axis. The names of the threads are displayed on the vertical axis in the order of their creation. Each color signifies a different thread status. Orange means that the thread was sleeping, green stands for a runnable thread while red is displayed if the thread was waiting for a monitor. You can zoom in and out to your desired detail level or have the time axis fit your windows size automatically.
If youre more interested in whats happening right now, the thread monitor view is the right place to look at. Here, you can sort threads, filter with respect to thread status and view additional information on each thread.
Should you ever have a deadlock in your application, the deadlock detection graph will help you analyze the involved threads and the locking situation. Simple deadlocks like the one shown could be worked out by hand from the other views, but for complicated deadlock involving a greater number of threads this view is indispensable.
Reducing general monitor contention and debugging locking sequences requires a detailed view of the current monitor usage and a history of all monitor-related events. JProfiler has both. Below you see the monitor usage history which shows a blocking event together with the stack trace of the waiting thread.
Keep an eye on your JVM
Monitoring cumulative parameters of the virtual machine can be a highly fruitful activity, even if everything seems to be all right. Measuring and observing parameters like heap size, object count, loaded classes and thread numbers can point to dangerous trends and problematic behavior to look out for. In its VM telemetry view section, JProfiler features various telemetry controls which provide you with the information you need to stay one step ahead.
The number of objects on the heap, split in arrays and non-arrays. This is your first stop if you are suspecting a memory leak. All objects with live references are included, as well as those which are unreferenced but the garbage collector hasnt had a chance to collect yet.
The garbage collector activity which displays freed and moved objects. If your application is thrashing the heap excessively, this will show up here. Moving large numbers of objects places a high burden on the virtual machine and can lead to temporary freezes. Mostly this occurs when the virtual machine is enlarging the heap.
The number of threads in the virtual machine, split in active and inactive threads. This is useful if you create a large number of threads and need information on changes in their total number and how many of them actually run.
Enhancements:
- New futures:
- rewritten eclipse 3.x integration
- rewritten IDEA 4.x integration
- IDE integration for JDeveloper
- IDE integration for Netbeans 4.0
- considerably reduced memory consumption
- improved long-term stability for profiling
- heap walker: in the cumulated incoming reference view, reference holders as well as referenced objects can be displayed and selected
- option to keep the profiled JVM alive
- support for Java Web Start 1.5
- CSV export for graphs
- enhancements in XML export for trees
- integration wizard for profiling servers in IBM WSAD
- integration wizards for Pramati 3.5 and Pramati 4.x application server
- integration wizard for Websphere 4.0 Advanced Edition
- integration wizard for Sun Java System Web Server
- integration wizard for Sun Java System Application Server
- integration wizard for Oracle 10g Application server
- integration wizard for Apple WebObjects Developer 5.x
- snapshot files (*.jps) can be opened from the command line and from the Windows explorer
- JBuilder IDE integration now supports JBuilder 2005
- much better appearance of the JProfiler GUI with Windows native look and feel
- JProfiler GUI now also runs under Java 1.5
- Bug fixes:
- monitor statistics were broken
- invalid class files caused a shutdown of the profiled application
- many bug fixes in the GUI

Guarded Memory Move project gets handy when you have to study buffer overflows and you need to catch them together with a "good" stack image. When a stack overflow has been exploited, the back trace is already gone together with good information about parameters and local variables, that are of vital importance when trying to understand how the attacker is trying to work out the exploit. The GMM library uses dynamic function call interception to catch the most common functions that are used by attackers to exploit stack buffers.
The GMM library uses the LD_PRELOAD capability and offers two services to the user. First of all, it avoids buffer overflow to allow the attacker to execute shell-code on your machine. Second, in case where an exploit is detected, the stack content is saved and a segmentation fault is triggered. The resulting core dump will then have all the necessary information to debug the exploit and fix the software. Internally, the library insert itself between the application and the glibc library and intercept functions that might lead to buffer overflow exploits. Before calling the glibc core function, the GMM layer saves part of the stack frame above the caller to a temporary location in its frame.
It also stores the previous three return addresses in its local storage before calling the glibc core function. When the core function returns, the GMM code samples again the previously recorded return addresses and, if they differ, it restores the previously saved stack frame and issue a segmentation fault. This with a clean stack frame, so that it can be inspected with a debugger. While other solutions exist to detect buffer overflow exploits, like for example StackGuard and StackShield, those differs from GMM in many ways. They live as gcc patches and do require you to rebuild your application to use their functionalities. The good of this approach is that every single function is protected against buffer overflows.
The bad of this solution is that every single function is protected against buffer overflows. That is, performance regression on the whole application, even if this is not really a huge problem when hunting for buffer overflows. Another solution similar to GMM is LibSafe, but it does not save and restore the stack frame by making it unusable for debugging. But lets see how GMM differs from the above listed solutions. First of all, GMM works everywhere there are stack frames and the gcc and glibc duo. That means that it is not limited to i386 only. And now the real reason for the GMM existence.
Enhancements:
- GCCs __builtin_return_address and __builtin_frame_address seems to return garbage instead of NULL at the last frame. This release fixes the problem.

MegamekNET project is a team-based multiplayer online campaign game.

MegaMekNET is based on FASAs Classic Battletech boardgame. It lets you join the war for the Inner Sphere.

The game allows you to join a house and lead units of towering Meks against other players online from around the globe.

Crush the other houses beneath your armoured feet in this turn-based strategy game.

You and your team fight to resurrect the Star League.

Azureus Speed Control is a project that enables automatic configuration of your upload limit. This addresses the problem of implicit additional upload when Azureus downloads with high speed, which can lead to connection choking. This is a problem specially for users with low upload bandwidth like German ADSL users.

If your download rate increases, the upload limit will be reduced by a value that can be customized. If the download rate decreases, the upload limit will increase again.