Free driver updates software for linux

debian-updates is a simple script that sends an email or displays console messages if any relevant Debian security updates become available. debian-updates is ideal for running from cron.

The Advanced Linux Sound Architecture is composed of several parts. The first is a fully modularized sound driver which supports module autoloading, devfs, isapnp autoconfiguration, and gives complete access to analog audio, digital audio, control, mixer, synthesizer, DSP, MIDI, and timer components of audio hardware.
It also includes a fully-featured kernel-level sequencer, a full compatibility layer for OSS/Free applications, an object-oriented C library which covers and enhances the ALSA kernel driver functionality for applications (client/server, plugins, PCM sharing/multiplexing, PCM metering, etc.), an interactive configuration program for the driver, and some simple utilities for basic management.
Main features:
- Efficient support for all types of audio interfaces, from consumer soundcards to professional multichannel audio interfaces.
- Fully modularized sound drivers.
- SMP and thread-safe design.
- User space library (alsa-lib) to simplify application programming and provide higher level functionality.
- Support for the older OSS API, providing binary compatibility for most OSS programs.

Nomad II supports the Creative Nomad II, IIc and II MG under Linux running USB for file transfers and other operations.
By default, the ownership of the newly created device file for the Nomad II is owned by root, without group/other read+write permissions.
make nomadii setuid root; on startup, nomadii
detects it is running in this mode and changes the owner of the device file to the original user, and then immediately drops back to the user ID of the original user (in order to minimize the possibility of security issues). This can be made with a number of techniques:
use the devuid, devgid or devmode mount options for usbdevfs, either in your /etc/fstab file or located where the mount call for usbdevfs is made (/etc/rc.d/rc.sysinit on RedHat 7.x); for example use devmode=0666 to open full access to all USB devices (with the attendant insecureness this creates). In a multi-user machine, setting up a group for USB would be the more secure option using this method.
locate and install the usb_perms daemon
use the hotplug package; this subsystem has good support for USB devices with user-level drivers such as this one with its usb.usermap launch method. The module launched by hotplug can be used to set ownerships or permissions on the device file as soon as the Nomad II is connected, and then even launch an xterm running a nomadii session. This is the most delicate of these methods to set up - sample instructions are given in the HOTPLUG file that comes with the source distribution.
Enhancements:
- Rename of utility to nomadii
- Availablility of RPM
- Full support of the Nomad II, IIc and II MG with latest firmware
- Autocorrection of bad data when getting files from the Nomad
- Much improved error detection and reporting
- Split of code into text front end and library
- Better name handling and progress reporting
- Updated support for nomadii-driver
- Better USB device permission options
- Added send/get methods
- Added support for multiple send, get and delete
- Hotplug documentation and scripts
- Many major and minor bug fixes

uLan Driver provides 9-bit message oriented communication protocol, which is transferred over RS-485 link.
Characters are transferred same way as for RS-232 asynchronous transfer except parity bit, which is used to distinguish between data characters and protocol control information. A physical layer consists of one twisted pair of leads and RS-485 transceivers.
Use of 9-bit character simplifies transfer of binary data and for intelligent controllers can lower the CPU load, because of the CPU need not to care about data characters send to other node. Producers of most microcontrollers for embedded applications know that and have implemented 9-bit extension in UARTs of most of todays MCUs. There is the list below to mention some of them:
- all Intel 8051 and 8096 based MCUs with UART
- members of Motorola 683xx family ( 68332, 68376, ... )
- Hitachi H8 microcontrollers
The driver is implemented as relatively independent layers and subsystems. Messages are prepared and received in the driver dedicated memory. This memory is divided into blocks with uniform size with atomic allocation routines.
When message is being stored into blocks, head of message with couple of data bytes is stored in the first allocated memory block. If all data cannot be stored in the first block, next blocks are allocated and linked together.
The message heads are linked in bidirectional linked lists of messages prepared for sending, processed messages and messages prepared for client notification. These lists or queues are main mechanism for transferring of messages between subsystems.
Link protocol is programmed as finite state automata with state stack, which state routines are executed by interrupt handler. State routine can return positive integer information, negative error notification or zero, which leads to wait for next interrupt. Information or error is used as input parameter when state routine is called.
When the state routine wants initiate transfer to another state routine it changes pointer to the actual state routine. If previous state routine returns nonzero value new routine is called immediately, in other case next interrupt invokes new state routine.
There is stack of callers of actual state routines which enables to constructs automata subsystems, which can be used in more places in main automata loop. Main purpose of this automata is to send or process messages coming in list of messages prepared for sending and if specified, move these messages onto list of messages prepared for client notification.
Received messages are put onto this list too. Subsystem is supervised by timeout handler, which can revitalize communication in case of die of other node. The interrupt and timeout handlers are fully SMP reentrant.
The automata subsystem uses pointers to chip driver routines for hardware port manipulation. This is only part dependent on used chip, today 82510, 16450 and OX16C950PCI. These routines can send and receive 9 bit character, connect to RS-485 line by the arbitration sequence, wait for specified time for character and initialize and close port.
File operation subsystem makes interface between OS kernel VFS and client message queues. It enables to prepare single or multi-frame messages and stores notifications of received or processed messages in clients private state structures. This part is heavily operating system dependent.
Enhancements:
- This release enables you to build the driver within the WDF framework for Windows.
- Updates to support the latest Linux 2.6.x kernels are included (tested to 2.6.19).
- Changes to allow stand-alone system-less build for ARM targets (LPC21xx) are included.
- The OMK has been selected as the default build.
- The "switch2std" script allows you to switch to the old build system.

EXAMPLE

# This is a really long synopsis, but hopefully it will give you an idea...

package MyPackage;

use Class::Driver;
use base q(Class::Driver);

our %drivers;

return 1;

sub new {
my($class, %args) = @_;
die "mime_type is required" unless($args{mime_type});
die "no driver to handle type $args{mime_type}"
unless($drivers{$args{mime_type}});
return $class->driver_load($drivers{$args{mime_type}}, %args);
}

sub driver_new {
my($class, %args) = @_;
return bless %args, $class;
}

sub driver_required { 1; }
sub driver_requied_here { 0; }

package MyPackage::avi;

use MyPackage;
use base q(MyPackage);
use Video::Info;

$MyPackage::drivers{video/x-msvideo} = avi;

return 1;

sub driver { "avi"; }

sub driver_new {
my($class, %args) = @_;
die "file is a required parameter for $args{mime_type} files"
unless($args{file});
$args{info} = Video::Info->new(-file => $args{file})
or die "Failed to create a Video::Info object for $args{file}";
return $class->SUPER::driver_new(%args);
}

sub duration {
my $self = shift;
return $args{info}->duration;
}

package MyPackage::mp3;
use base q(MyPackage);
use MP3::Info;

$MyPackage::drivers{audio/mpeg} = mp3;

## (etc...)

package main;

my $foo = MyPackage->new(file => foobar.mp3, mime_type => audio/mpeg);
print "foobar.mp3 is ", $foo->duration, " seconds long.n";

iODBC is a cross-platform Driver Manager that comforms to the Microsoft ODBC 2.x & 3.x and X/Open SQL CLI data access specs.
iODBC Driver Manager and SDK enables the development of database-centric solutions that are both database and platform independent.
What is the ODBC Value Proposition?
The ability to develop applications independent of back-end database engine.
What is iODBC?
iODBC is the acronym for Independent Open DataBase Connectivity, an Open Source platform independent implementation of both the ODBC and X/Open specifications. It is rapidly emerging as the industry standard for developing solutions that are language, platform and database independent.
What is the iODBC Value Proposition?
The ability to develop applications independent of back-end database engine, operating system, and for the most part programming language. Although ODBC and iODBC are both C based Application Programming Interfaces (APIs) there are numerous cross language hooks and bridges from languages such as: C++, Java, Perl, Python, TCL etc.
iODBC has been ported to numerous platforms, including:
Linux (x86, Itanium, Alpha, Mips, and StrongArm), Solaris (Sparc & x86), AIX, HP-UX (PA-RISC & Itanium), Digital UNIX, Dynix, Generic UNIX 5.4, FreeBSD, MacOS 9, MacOS X, DG-UX, and OpenVMS.
This is a great SDK for porting WIN32-based ODBC applications to Linux and other OS platforms.
Enhancements:
- Added support for FileDSN
- Added support for Connection Pooling
- Added check for tracefile size
- Call ODBC 2.x functions in driver if application uses ODBC 2.x only calls
- Fixed problem parsing driver result in SQLSetStmtAttr
- Fixed source code readability
- Fixed bug in overwriting driver name
- Fixed check for /Library/ODBC for Mac OS X
- Fixed prototypes
- Rewrote bootstrap script and configure summary
- Use localtime_r in tracing when available
- Fixed build issues with Mac OS X
- Small code cleanups and fixes

The intel-wings project is a Linux driver for the Intel Wireless Series of input devices.
Somehow, Intel managed to avoid using the USB Human Interface Device standards with their wireless gamepads.
All other USB gamepads work out-of-the-box: plug it in, and the computer knows that it has an X axis, a Y axis, and six buttons. Not Intel. Thats where intel-wings comes in.
Wireless Series?
Yes, youve seen them. Everyone hated them. The keyboards were of poor manufacturing, the mice eat batteries like theres no tomorrow, and the whole system was ridiculously expensive. They were killed off by Intel several years ago -- after hitting the shelves and getting a lukewarm reaction, manufacturing was stopped, and support was terminated 18 months after release.
All of these complaints are valid. On the other hand, when used infrequently, the mice last a few months, and work great on a glass coffee table in my living room. (A newer wireless optical mouse wouldnt work.)
The gamepads are actually pretty fun, in my opinion: you can have a whole bunch of them attached to one base station, which is great for playing old console games with friends. You can get a complete set of devices for $10 on eBay, and with Linux-based PVRs becoming increasingly common, I find my devices to be a great addition to my living room.
Note that I wouldnt recommend the mice to anyone that uses their computer on a regular basis, but its easier for navigating menus than a remote control. In my opinion, the Intel Wireless Series devices on Linux PVRs are the way to go.
Enhancements:
- Preliminary keyboard support was added.
- The Intel wireless keyboards are at least partially functional.

if_rate measures and prints some statistics about the rate of traffic through network interfaces (like iptraf).
This is a simple program who read from /proc/net/dev and write some real-time statistics about the trafic on interfaces. You can use it free (and without waranties), i hope you will find it usefull and you will use it only for moral .
These are the known bugs:
- some interface drivers have bugs in the update of the counter, not my fault...
- some drivers have time counters updated at more than 1 second interval, to have exact averages you must set an interval much bigger than this interval (example: "./if_rate 10")
Enhancements:
- the rate is more accured, now I use gettimeofday() for exact time measuring.
- more space for gigabit counters
- accept argument - number of seconds between counters is settable