Ports Search

[ excerpt from developer's www site with modifications ] The idea was to use the high performance Metakine M2Requantiser to create a transcoder for Linux for shrinking the content of a DVD9. This would enable backups on cheap single layer DVDRs (double layer burners weren't even available that time). Vamps builds a wrapper around the requantizer to extract the elementary MPEG2 video stream from the DVD's program stream, feed it through the requantizer and finally re-pack it into the program stream again. Besides this, Vamps allows the selection of both audio and subtitle streams that should be copied into the output stream. This gives another small gain of disk space, since unwanted streams may be discarded. Summed up, Vamps is only a very basic, but nevertheless essential tool to transcode DVD videos to a smaller size. Vamps does not need to write temporary data files, which is a major pro. Vamps is very fast. The downside is, that Vamps is not capable of making DVD backups on its own.

http://www.linuxtv.org/vdrwiki/index.php/Streamdev-plugin This PlugIn is a VDR implementation of the VTP (Video Transfer Protocol) Version 0.0.3 (see file PROTOCOL) and a basic HTTP Streaming Protocol. It consists of a server and a client part, but both parts are compiled together with the PlugIn source, but appear as separate PlugIns to VDR. The client part acts as a full Input Device, so it can be used in conjunction with a DXR3-Card, XINE, SoftDevice or others to act as a working VDR installation without any DVB-Hardware including EPG-Handling. The server part acts as a Receiver-Device and works transparently in the background within your running VDR. It can serve multiple clients and it can distribute multiple input streams (i.e. from multiple DVB-cards) to multiple clients using the native VTP protocol (for VDR-clients), or using the HTTP protocol supporting clients such as XINE, MPlayer and so on. With XMMS or WinAMP, you can also listen to radio channels over a HTTP connection.

OpenPGM is an open source implementation of the Pragmatic General Multicast (PGM) specification in RFC 3208 available at www.ietf.org. PGM is a reliable and scalable multicast protocol that enables receivers to detect loss, request retransmission of lost data, or notify an application of unrecoverable loss. PGM is a receiver-reliable protocol, which means the receiver is responsible for ensuring all data is received, absolving the sender of reception responsibility. PGM runs over a best effort datagram service, currently OpenPGM uses IP multicast but could be implemented above switched fabrics such as InfiniBand. PGM is appropriate for applications that require duplicate-free multicast data delivery from multiple sources to multiple receivers. PGM does not support acknowledged delivery, nor does it guarantee ordering of packets from multiple senders. PGM is primarly used on internal networks to help integrate disparate systems through a common communication platform. A lack of IPv4 multicast-enabled infrastructure leads to limited capability for internet applications, IPv6 promotes multicast to be a part of the core functionality of IP but may still be disabled on core routers. Support of Source-Specific Multicast (SSM) allows for improved WAN deployment by allowing end-point router filtering of unwanted source traffic

ccrypt is a utility for encrypting and decrypting files and streams. It was designed to replace the standard Unix crypt utility, which is notorious for using a very weak encryption algorithm. ccrypt is based on the Rijndael cipher, which is the U.S. government's chosen candidate for the Advanced Encryption Standard (AES, see http://www.nist.gov/aes/). This cipher is believed to provide very strong security. Unlike Unix crypt, the algorithm provided by ccrypt is not symmetric, i.e., one must specify whether to encrypt or decrypt. The most common way to invoke ccrypt is via the commands ccencrypt and ccdecrypt. There is also a ccat command for decrypting a file directly to the terminal, thus reducing the likelihood of leaving temporary plaintext files around. In addition, there is a compatibility mode for decrypting legacy Unix crypt files. Encryption and decryption depends on a keyword (or key phrase) supplied by the user. By default, the user is prompted to enter a keyword from the terminal. Keywords can consist of any number of characters, and all characters are significant (although ccrypt internally hashes the key to 256 bits). Longer keywords provide better security than short ones, since they are less likely to be discovered by exhaustive search.

The FreeBSD LiveCD Tool Set main goal is allowing one to generate custom FreeBSD Live CDs. FreeBSD LiveCD was born as a Brazilian FreeBSD User Group (www.fugspbr.org) project. The objective was to create a tool that would allow us a safe diagnostic method under emergency enviroments and specially as a rescue disk where FreeBSD partitions could only be accessed (mounted) externally. What is LiveCD? Its such a simple answer, it is nothing but a set of patches applied to the FreeBSD Initialization files allowing the system to run from a CDROM, setting the best way to either mount under Memory File System (MFS) or Virtual Nodes (vnodes) those filesystems that need Write and Read access. Slices that just need Read access are still run from the CD. Can I use it to install FreeBSD? Yes, with recent revision 1.2, it can install a FreeBSD system without any other disks. It also support batch operation mode for automated installation processes. Is LiveCD any different from an ordinarily installed FreeBSD system? It is a completely functional FreeBSD system just like any ordinarily installed one. You will be able to both run any applications and mount any filesystems as any FreeBSD system would allow you. Edson Brandi <ebrandi@fugspbr.org>

This Perl script is designed to load a number of directories into Subversion. This is useful if you have a number of .zip's or tar.{Z,gz,bz2}'s for a particular package and want to load them into Subversion. This script is part of the Subversion distribution and it is assumed that it can be used under the same license terms as Subversion itself.

http://www.linuxtv.org/vdrwiki/index.php/Remote-plugin This plugin extends the remote control capabilities of vdr. The following remote control devices are supported: (a) Linux input device driver ('/dev/input/eventX', X=0,1,2,...) (currently not supported on FreeBSD) (b) keyboard (tty driver): /dev/console, /dev/ttyX (c) TCP connection (telnet) (d) LIRC (e) some(?) FreeBSD uhid(4) devices (experimental support added by this port) To use, add something like this to vdr_flags: '-Premote -h /dev/uhid0', (re)start vdr, then the osd should ask you to configure the remote by pressing the buttons you want to assign. Note: If your remote is detected as a keyboard you'll have to tell ukbd(4) to ignore it first by doing (as root) something like: usbconfig add_dev_quirk_vplh 0x1241 0xe000 0 0xffff UQ_KBD_IGNORE (and possibly unplug it for a moment or reset it via usbconfig, 0x1241 there is the vendor id, 0xe000 the product id of the device, you can get yours by doing usbconfig -d 1.2 dump_device_desc and looking for idVendor and idProduct, -d 1.2 there corresponds to ugen1.2 listed by usbconfig w/o args.) You can check with: usbconfig show_ifdrv if the device is then listed as ugen...: uhid... you're good to go. 2nd note: If vdr cannot open your uhid device check it is not claimed by xorg: fstat |grep uhid If it is you may need an xorg.conf(5) with manually defined InputDevice sections for mouse and keyboard and Option "AutoAddDevices" "False" in the ServerFlags section. And if for some reason you want to reassign the buttons on the remote you can stop vdr and do: touch /usr/local/etc/vdr/channels.conf and/or remove uhid entries from /usr/local/etc/vdr/remote.conf . When you then start vdr again it should ask to configure the remote again.

It all started when we got some new routers, which told me the following when trying to upload configuration or download images from it: The TFTP server doesn't support the blocksize option. My curiousity was triggered, it took me some reading of RFCs and other documentation to find out what was possible and what could be done. Was plain TFTP very simple in its handshake, TFTP with options was kind of messy because of its backwards capability: The first packet returned could either be an acknowledgement of options, or the first data packet. Going through the source code of src/libexec/tftpd and going through the code of src/usr.bin/tftp showed that there was a lot of duplicate code, and the addition of options would only increase the amount of duplicate code. After all, both the client and the server can act as a sender and receiver. At the end, it ended up with a nearly complete rewrite of the tftp client and server. It has been tested against the following TFTP clients and servers: - Itself (yay!) - The standard FreeBSD tftp client and server - The Fedora Core 6 tftp client and server - Cisco router tftp client - Extreme Networks tftp client It supports the following RFCs: RFC1350 - THE TFTP PROTOCOL (REVISION 2) RFC2347 - TFTP Option Extension RFC2348 - TFTP Blocksize Option RFC2349 - TFTP Timeout Interval and Transfer Size Options RFC3617 - Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP) It supports the following unofficial TFTP Options as described at http://www.compuphase.com/tftp.htm: blksize2 - Block size restricted to powers of 2, excluding protocol headers rollover - Block counter roll-over (roll back to zero or to one) From the tftp program point of view the following things are changed: - New commands: "blocksize", "blocksize2", "rollover" and "options" - Development features: "debug" and "packetdrop" If you try this tftp/tftpd implementation, please let me know if it works (or doesn't work) and against which implementaion so I can get a list of confirmed working systems.