set through sysctl (e.g. debug.gspca.compress, debug.gspca.autobright)
are updated every time the device is open() instead of just loading
them at device connect time.
All the changes included in this file have been passed to the author
of the gspca driver so hopefully in future releases we will not need
patches anymore.
(available under /proc on Linux) as a sysctl tree debug.{drivername}
With this feature you can, as an example, set
sysctl debug.gspca.compress=1 and sysctl debug.gspca.autoexpo=0
to speed up capture on some cameras.
This version also includes some pwcview changes to display up
to 4 copies of the grabbed image, with various mirroring options.
Rancid monitors a router's (or device's) configuration, including software
and hardware (cards, serial numbers, etc), using CVS. Rancid currently
supports Bay routers, Cisco routers, Juniper routers, Catalyst switches,
Foundry switches, Redback NASs, ADC EZT3 muxes, MRTd (and thus likely IRRd),
Alteon switches, HP procurve switches, Hitachi routers.
Rancid logs into each of the devices in a router table file, runs various
commands, chomps the output, and emails any differences ( sample) from
the previous collection to a mail list.
A looking glass is also included with rancid, based on Ed Kern's in use on
http://nitrous.digex.net/. Rancid version has added functions, supports cisco,
juniper, and foundry and uses the login scripts that come with rancid;
so it can use rsh, telnet, or ssh to connect to your router(s).
WWW: http://www.shrubbery.net/rancid/
PR: 110607
Submitted by: Janos Mohacsi <janos.mohacsi@bsd.hu>
Repocopy by: marcus
gcc-4.2. Add some 64-bitness patches. Enable automatic post-build tests.
Attempt to allow ESound and NAS modules via OPTIONS:
PR: ports/102413
Both are on by default ATM...
- A new version of libSpiff has been released. This release includes a C
interface, next to the existing C++ bits. libSpiff now installs a shared
object, using libtool.
PR: ports/110778
Submitted by: maintainer (Ed Schouten)
Its primary goal is to be correct and its secondary goal is to be fast.
To reach the latter goal it was written in C.
As this is the n-th-something JSON module on CPAN, what was the reason
to write yet another JSON module? While it seems there are many JSON
modules, none of them correctly handle all corner cases, and in most
cases their maintainers are unresponsive, gone missing, or not listening
to bug reports for other reasons.
WWW: http://search.cpan.org/dist/JSON-XS/