Free common vulnerability scoring system software for linux

CUPS provides a portable printing layer for Unix(r)-based operating systems. Common UNIX Printing System has been developed to promote a standard printing solution for all Unix vendors and users.

CUPS provides the System V and Berkeley command line interfaces, and uses the Internet Printing Protocol ("IPP") as the basis for managing print jobs and queues. The Line Printer Daemon (LPD) Server Message Block (SMB), and AppSocket (a.k.a. JetDirect) protocols are also supported with reduced functionality.

CUPS adds network printer browsing and PostScript Printer Description ("PPD") based printing options to support real world printing under UNIX. It includes an image file RIP that supports printing of image files to non-PostScript printers.

A customized version of GNU Ghostscript 7.05 for CUPS called ESP Ghostscript is available separately to support printing of PostScript files within the CUPS driver framework. Sample drivers for Dymo, EPSON, HP, and OKIDATA printers are included that use these filters.

Aigaion Bibliography System is a Web-based shared bibliography manager built on PHP/MySQL. Aigaion Bibliography System project is based on the BibTeX format, but has support for other formats as well.
Main features:
- extensive support for organizing a bibliography in a topic structure
- personal and public annotations on each publication
- multi-user support
- easy import/export
- intuitive user interface
Enhancements:
- A remote SQL injection vulnerability issue was fixed.

DEX Extensible Operating System is an operating system specifically designed for educational and research use. DEX Extensible Operating System allows for the dynamic reconfiguration and customization of various system services using concepts found in extensible operating systems.
It aims to create an operating system design thats easy to understand while having features that are common in todays modern operating systems. Unlike other small operating systems, it is powerful enough to support simple applications that require multithreading and file management.
Its architectural design, with the help of Aspect-Oriented programming, enables easy modification and extensibility. It was developed in C and runs on PCs with 80386 processors or higher.
Enhancements:
- This version is released with a floppy image and the kernel source code.
- The release contains peformance enhancements, source code clean-ups, and a makefile for use with GNU make.

Linux Mobile System project (LMS) is a full Linux system whose support is the new USB Flash Memory Drives. The intention is to boot any PC with USB support with our system and therefore we will have every administration and analysis applications that we have selected, so we will not need install it. This way, always we will be able to get our Linux system ready to use in our pocket.
This project arose with the intention to study the Linux system of exhaustive way and simultaneously enjoy with it. The initial idea is to fuse two separated disciplines: the programming and the systems management. So well center our study in the denominated "system programming, as much networking level as at device level (drivers).
Main features:
- To initiate our Linux system from memories flash USB.
- The system will be a selection of common GNU tools in every system: disk diagnosis, memory, hardware, networks monitoring tools, etc.
- LMS Tux
- As far as possible well develop new tools and/or utilities with the objective to study deeply the underlying technology.
- The programming languages used will be C, C++, Python and Perl, without forget the system shell scripts.
- The resources minimization (disk space, memory...) isnt a functional objective of the developments.
LMSs main aim is to achieve a highly specialized distribution of GNU/Linux which can carried through the USB Flash Memory Drives. Once the distribution is ready in the USB device, it can be carried in your own pocket and you can start up any PC x86 with no need to install it directly in the PC.
The LMS system is aimed at the development of specific tasks such as network administration, security analysis of networks, and recovery and repair of host data, as well as all information exchange, which is what makes it different from other portable systems such as "live CDs". The main idea is to carry all the potency of Linux and our tools in our own pockets, ready to be used.

Common Lisp Kanji Drill, or CLKD in short, is a newly-released program for learning the meanings of Chinese/Japanese characters (kanji) by means of repeated tests. The project is developed using CLISP, and runs on GNU/Linux and on MS Windows under Cygwin. CLKD uses a web browser as its interface. (These work best: Firefox 1.0.4 or newer; or Internet Explorer 7 or newer),. Japanese fonts are required.

CLKD is not intended for complete beginners in Japanese or Chinese to just start learning characters by rote. Its best to learn something about the structure of these characters by reading a few good books about them. It helps to know how to write them, how to count strokes, and how to look up characters in dictionaries which classify them by radical and components.

But all these resources still leave a big task: the raw memorization of hundreds and hundreds of characters. That is where a tool like CLKD becomes valuable.

CLKD is ideally suited to someone who has already broken through the unfamiliarity barrier: the student who can already recognize familiar components in an unfamiliar character and mentally form a mnemonic to which he or she can anchor the meanings of that character, and who is ready to begin internalizing a large number of characters.

Common Media Input Layer (CMIL) is an C++ OO framework designed to improve the state of cross-platform input handling in games and other similar applications.
CMIL was created out of the belief that the methods used in most media APIs perform input handling in a confusing, difficult, inflexible fashion. CMILs goal is to address this issue by establishing a flexible, easy to use, human readible, OO abstraction layer. This layer specifically allows for media and input device abstraction.
Main features:
- easiliy build complex input sequences, including timed inputs, which do not impose restrictive notions of what is and isnt a moderator on the user
- custom input device configurations, IE: Users can swap input device configurations on the fly and create their own representation of a custom device using the framework facilities

GNU ccRTP is an implementation of RTP, the real-time transport protocol from the IETF (see RFC 3550, RFC 3551 and RFC 3555). ccRTP is a C++ library based on GNU Common C++ which provides a high performance, flexible and extensible standards-compliant RTP stack with full RTCP support. The design and implementation of ccRTP make it suitable for high capacity servers and gateways as well as personal client applications.
In designing ccRTP, we have taken into account that RTP has been defined as an application level protocol framework rather than a typical Internet transport protocol such as TCP and UDP. Thus, RTP is hardly ever implemented as a layer separated from the application.
Consequently, RTP applications often must customize the adaptable RTP packet layout and processing rules, timing constraints, session membership rules as well as other RTP and RTCP mechanisms. ccRTP aims to provide a framework for the RTP framework, rather than being just an RTP packet manipulation library.
Support for both audio and video data is also considered in the design of ccRTP, that can do partial frame splits/re-assembly. Unicast, multi-unicast and multicast transport models are supported, as well as multiple active synchronization sources, multiple RTP sessions (SSRC spaces), and multiple RTP applications (CNAME spaces). This allows its use for building all forms of Internet standards based audio and visual conferencing systems.
GNU ccRTP is threadsafe and high performance. It uses packet queue lists for the reception and transmission of data packets. Both inter-media and intra-media synchronization is automatically handled within the incoming and outgoing packet queues. GNU ccRTP offers support for RTCP and many other standard and extended features that are needed for both compatible and advanced streaming applications.
It can mix multiple payload types in stream, and hence can be used to impliment RFC 2833 compliant signaling applications as well as other specialized things. GNU ccRTP also offers direct RTP and RTCP packet filtering.
GNU ccRTP uses templates to isolate threading and sockets related dependencies, so that it can be used to impliment realtime streaming with different threading models and underlying transport protocols, not just with IPV4 UDP sockets. For a more detailed list of ccRTP features you can have a look at the programmers manual.
At its highest level, ccRTP provides classes for the real-time transport of data through RTP sessions, as well as the control functions of RTCP.
The main concept in the ccRTP implementation of RTP sessions is the use of packet queues to handle transmission and reception of RTP data packets/application data units. In ccRTP, a data block is transmitted by putting it into the transmission (outgoing packets) queue, and received by getting it from the reception (incoming packets) queue.
Main features:
- Highly extensible to specialized stacks.
- Supports unicast, multi-unicast and multicast. Handles multiple sources (including synchronization sources and contributing sources) and destinations. Also supports symmetric RTP.
- Automatic RTCP functions handling, such as association of synchronization sources from the same participant or NTP-RTP timestamp mapping.
- Genericity as for underlying network and transport protocols through templates.
- It is threadsafe and supports almost any threading model.
- Generic and extensible RTP and RTCP header validity checks.
- Handles source states and information as well as statistics recording.
- Automatically handles SSRC collisions and performs loop detection.
- Implements timer reconsideration and reverse reconsideration.
- Provides good random numbers, based on /dev/urandom or, alternatively, on MD5.
There are several levels of interface (public interface, public or protected inheritance, etc) in ccRTP. For instance, the rtphello demo program distributed with ccRTP just uses the public interface of the RTPSession class and does not redefine the virtual method onGotSR, thus what this program knows about SR reports is the information conveyed in the last sender report from any source, which can be retrieved via the getMRSenderInfo method of the SyncSource class.
On the contrary, the rtplisten demo program redefines onGotSR by means of inheritance and could do specialized processing of these RTCP packets. Generally, both data and control packets are not directly accessible through the most external interface.
All this functions are performed through a few essential classes and types. The most basic ones are the enumerated type StaticPayloadType, and the classes StaticPayloadFormat and DynamicPayloadFormat.
The most important ones are the classes RTPSession, SyncSource, Participant and AppDataUnit, that represent RTP sessions, synchronization sources, participants in an RTP application, and application data units conveyed in RTP data packets, respectively.
When using ccRTP, both sending and receiving of data transported over RTP sessions is done through reception and transmission queues handled by the RTP stack. In the most common case, a separate execution thread for each RTP session handles the queues. This case is the threading model that we will generally assume throughout this document. Note however that ccRTP supports other threading models, particularly ccRTP supports the use of a single execution thread to serve a set of RTP sessions. It is also possible to not associate any separate thread with any RTP session, manually calling the main data and control service methods from whatever other thread.
The basic idea for packet reception with ccRTP is that the application does not directly read packets from sockets but gets them from a reception queue. The stack is responsible for inserting received packets in the reception queue and handling this queue. In general, a packet reception and insertion in the reception queue does not occur at the same time the application gets it from the queue.
Conversely, the basic idea for packet transmission with ccRTP is that packets are not directly written to sockets but inserted in a transmission queue handled by the stack. In general, packet insertion and transmission occur at different times, though it is not necessary.
In order to use ccRTP, you must include the main header (#include < ccrtp/rtp.h >. Two additional headers are provided by ccRTP:
#include < ccrtp/rtppool.h
Classes for pools of RTP service threads.
#include < ccrtp/rtpext.h >
Classes for RTP extensions which are not mature yet.
You must also link in the library, currently ccrtp1.
Enhancements:
- Brand new support has been introduced for Secure RTP Profile (srtp) as per RFC 3711.
- This release also supports a new add-on package, libzrtpcpp, that directly offers native zfone (zrtp) compatible encryption capabilities to Common C++ RTP based applications.
- This is the first softphone client to use both Common C++ RTP srtp and zrtp support.