Free arch supports software for linux

ArchWay is a full-featured graphical user interface for the GNU Arch revision control system.

It includes a set of specialized tools to make project development and tracking more effective, including an archive browser, inventory manager, and merge interface.

ArchLog is a log-oriented GUI for the Arch revision control system. ArchLog allows you to take notes as you hack, structuring the changes by categories. At commit time, ArchLog will generate a consistently and nicely-formatted log file.

It features assigning new versions to a project tree, adding/removing files for a project, packing a project into archives (tar.gz, tar.bz2, tar, zip), a todo manager with categorized tasks, global or per-project preferences, TODO file generation, and full customization from the GUI.

Archie project is a complete live Arch linux system (v0.7) to be run from a cd/usb, built with the KISS philosophy in mind. No packages have been stripped to provide a full Arch linux system, yet deliver fastest performance with no extensive bloating.
Archie uses its own hw-detection tool (lshwd) ideally to support a wide range of hardware with low detection time. Archie also provides extended features like multi-lingual, nesting capabilities and hd-install.
Main features:
- KISS
- Performance, performance, performance
- Unique hw-detection tool (lshwd)
- Automatic desktop/optional startup dialogs
- nesting root (/) or home (/home) directories
- hd-install

ArX is a Revision Control System (RCS), like CVS, Subversion, or GNU arch. It manages "archives" (collections of files), such as source code files for a software project.
ArX tracks the history of each file, along with change comments, version tags, forks and branches, etc. It can store files and documents of any kind, but the largest benefits are with text files, rather than binary files.
Main features:
- Ease of learning and use
- Powerful branching and merging features
- Speed, even when working with large repositories
- Effective distributed development
- Friendly and helpful user and developer communities
- Cryptographic data integrity features
- Ability to publish archives on almost any server
- Portability to multiple operating systems (still in progress)
Like CVS (and most modern RCS tools), ArX uses an "optimistic" locking model, which allows multiple developers to modify the same file at the same time, and then resolves any conflicts as each developer checks in his or her work. While this may sound scary if you are used to systems that "lock" files, it actually works very well, as confirmed by the thousands of projects that have used this approach (in CVS) for many years.
Unlike CVS and most traditional RCS tools, ArX is "distributed", which means that ArX does not require a central server. Each developer can maintain their own "archive" of their projects, but can easily share their work with other developers. This modern design works well with teams that are geographically distributed, and especially with teams where some contributors are not part of the core team.
ArX includes an optional patch queue manager to enable centralized, CVS-style, development when desired. ArX differs from many of the newer distributed SCM tools in that it does not require every working tree to contain an entire copy of the archive history.
Each archive can store multiple branches, each of which could be checked out in multiple working trees. Other tools may use the terms "patch pooling" or "centralized storage" for this type of feature, and it is important for efficient branching on systems without hardlinks. Also, ArX archives can link to other archives (including remote archives) for older history, allowing branches of remote projects to be very small and fast.
Another important feature of ArX is that an archive can be published on any HTTP web server. It does not require any special code running on the server, which has some significant advantages: First, it allows projects to host their code on almost any inexpensive web site, including the free personal home pages offered by many ISPs. Second, it keeps the server very secure, because the only service required is a standard web server such as Apache or Boa.
Enhancements:
- ArX now uses three-way merging as a default, and supports third party merge tools.
- ArX is also much more clever about renames.
- "merge" now uses the --update option instead of using heuristics.
- ArX now records when there are conflicts in the tree, and will not let you commit unless they are resolved.
- ArX now uses -v and -q for verbosity.
- "commit" now supports --author and --date options for Tailor.
- The patch queue manager has been updated, and some small bugs were fixed.

Crossfire TRT project is an advancement of the crossfire multi-user RPG game. Unlike the original project, it focuses mainly on stability and playability, but also adds modern technology such as map scripting, Perl server extensions, asynchronous I/O, higher resolution graphics, and better client support.
Main features:
- Death is not permanent, and you can get back all lost stats and experience by playing a game in a special place named Nimbus. You are teleported there when you die and you have to play a game (currently minesweeper) to get out.
- Friendly fire is disabled and playerkilling is also modified. You can only kill another player when you and the other player are hostile. To become hostile, you have to visit the church of Gorokh in Scorn and talk to the priest. To become peaceful again, visit the curch of Valriel and talk to its priest.
- Invitation of other players to where you are is possible with the invite command. You have to solve the invitor quest (see below in maps) to be able to use the command.
- You can follow other players with the follow command when you stand next to the player you want to follow.
- Pet monsters and summoned creatures will not stand in the way of other party members, making it bearable to play with summoning skills in a party.
- Map and graphics artists are working on improved graphics and new maps and quests.
- A new currency: the Royalty. Its worth 100 Platinum and is made of paper. (The bank script was completly rewritten in Perl)
- The communication commands have been rewritten in Perl and an ignore command was added.
- Trade shops have been implemented in Perl, which allows the player to trade items when they are offline.
- Big 64x64 faces and tiles have been introduced, which have a higher detail level than the old 32x32 tiles, and can be used with the CFPlus client.
Enhancements:
- optimised event invocation (non-wanted events can now be skipped with 4-5 inlined instructions).
- complete rewrite of town_portal: it now creates a portal to the "nearest" town only, travel is only possible to the town and back, anybody can use it (also removes one of the remaining syncpoints in the server).
- complete rewrite of the range/attack skill slot system: there are now two slots, one for combat, one for ranged attacks.
- introduce the concept of a current weapon (either a ranged or a combat weapon/skill/tool) and switch between them as needed.
- rewrite bow code so bows get more useful: apply damage, attacktype and other stats to the arrows and treat bows as weapons. also rebalance the missile weapons skill so its damage increases with level.
- rewrite the complete player speed logic: weapon_speed now works as documented and there are no unnatural speed boosts.
- implement a utility - cfutil - that simplifies arch and map installation, replacing the old collect scripts and simplying deployment by scaling and cutting faces as required.
- simplify the map protocol extensively by taking advantage of missing bigfaces, speeding up map generation immensely.
- implement inherit keyword allowing archetypes to inherit from other archetypes.
- rationalise archetype, region and treasurelist file format into a single file format and make them reloadable asynchronously.
- make the worldmap, facedata (smoothing, faces, magicmap) reloadable at runtime.
- implement 64x64 faceset support.
- implement fxixsx protocol that saves a lot of bandwidth over the old image/face/smooth packets and allows images > packetsize, incremental and background transfers.
- implement a bandwidth-saving smoothing protocol that works on a face basis as opposed to a mapspace basis.
- the server can now rate-limit image uploads to not exceed a certain (client-configurable) speed while guarenteeing full freedom of movement.
- implement new ex command to request item descriptions.
- implement new msg command for in-game messages with meta information (using xml).
- enforce utf-8 for all text messages.
- added micropather (not used yet).
- many, many bugfixes.

Jacman project is a frontend for pacman software management software that comes with the equally excellent ArchLinux. Hopefully the "J" makes it obvious that this is a Java application.
Archs philosophy is to keep things simple and to keep the user in control. Generally, GUI based configuration tools were deemed "anti-Arch" as they tended to contradict the philosophy by concealing functionality.
Whilst developing Jacman, it has been a design goal to not break the philosophy, but inevitably it does. Whilst Jacman is only a front-end to pacman, it doesnt provide access to all of pacmans functionality.
However, there was a reason for that! I wanted Jacman to provide a visual window for only a subset of common tasks: installing, removing, updating and re-syncing. Some people may like this, as it allows people to quickly explore which packages are available.
Main features:
- installing new packages.
- updating installed packages.
- removing unwanted packages.
- rolling back packages to a previously installed version.

Nabu is a simple framework that extracts chunks of various types of information from documents written in simple text files (written with reStructuredText conventions) and that stores this information (including the document) in a remote database for later retrieval.
The processing and extraction of the document is handled on a server, and there is a small and simple client that is used to push the files to the server for processing and storage (think rsync). The client requires only Python to work.
The presentation layer is left unspecified: you can use whichever web application framework you like to present the extracted data in the way that you prefer.
Main features:
- It is flexible: you can use
- any text editor you like to edit the files;
- any source code control system you like to store and maintain them (or none);
- any database for storage;
- and any web application framework for presentation. Nabu does not dictate how the information is presented/served to the clients;
- you edit files locally, not in a bleeping web browser window (programmers will appreciate the value of this), in your favourite editor environment;
- the organization of the source files in subdirectories has nothing to do with how the content is presented. We use a unique ID system (similar to arch) where your document to be published must contain a unique string to mark it with that id. You can put that string in a reStructuredText comment or a bibliographic field. Unlike Wikis, this allows you to change the title of your documents while keeping the possibility of a permanent link to them.
- It effectively offers you a sandbox for creating content, and then how you organize and present the content is dictated by ways that you decide, most likely independent of the source file organization structure;
- the input data can be scattered over many files, it does not have to be stored in files per-category (for example, you dont have to store all your "contacts" in a single "address book" file, they can be found within/across all your body of published file and a server might present as a single list if desired). I conjecture that this may be closer to how humans think of this data. This body of files can be used to create a mind-mapping system;
- we recognize that the value of the information lies in the source itself, the text files. This valuable source remains with you, and you are free to manage them in any way you prefer, with any version control system you like (if you want to do that). You can completely dump the data stored in the database and rebuild it from the text files;
- various semantic chunks of content are automatically extracted from your document. These semantic things are easily written with little code and are configurable. Nabu comes with example content extractors;
- a light-weight program with minimal dependencies is used to upload the files to the server. The server processes the files for content. This maximizes the potential that you will be able to use Nabu anywhere, on any platform. The client only requires Python to work;