[ 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>
这个 Perl 脚本是设计用来加载很多目录到 Subversion 的。这在你有许多 zip 或
tar.{Z,gz,bz2} 文件包要加载到 Subversion 时很有用。
这个脚本是 Subversion 分发包的一部分,并且大家认为它可以和 subversion
本身使用相同的授权来使用。
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.