List of vendors and their associated driver support information gleaned from the net.

• Lucent / Agere WinModems. Unfortunately, this chipset/driver combination does not support multiple instances.
• PCTel chipsets have found their way into a large number of systems. The best source for drivers appears to be at the PCTel section of the Technion University website.
• Rockwell
• Conexant chipsets have Linux drivers built for them by Linuxant. Just as every other soft modem vendor out there, Conexant is not making the entire driver freely available and thus the purists will have to put up with the tainted kernel complaints. Acoording to the Linuxant INSTALL page for the HCF controller-less driver, multiple instances will work fine. However, seeing that nothing is free, this driver costs money to operate at speeds above 14.4Kbps!
• Motorola provides its own (tainted) drivers for the SM56 family of modems
• Cirrus Logic CL-MD5620DT
• Intel MD5628D-L-C and DQ82536EP chipsets
  Pre-compiled binary drivers for any number of Linux flavors can be downloaded from Intel, but please leave a message for them complaining about the lack of source code!

A good summary of the state of Linux support for WinModems is also available at Modemsite.com although you cannot download anything from them without paying a subscription fee.
A well-maintained, open site on all things LinModem is maintained by Jacques Goldberg at Technion University in Israel.

Once an organization finds itself relying more and more on the timeliness and cleanliness of its inbound e-mail, it is time to introduce a centralized e-mail server into the infrastructure. There are many commercial solutions out there but in this article I will briefly describe how to build such a server out of purely Open Source Software (OSS).

The server, of course, will run Linux. (PBnJ Solutions uses RedHat but you can choose any distribution you prefer.) The stock server install will get you all the sendmail pieces you need but just to be sure, look for the

/usr/share/sendmail-cf

Our sendmail routing rules will make use of procmail for final delivery by way of the SpamAssassin spam filtering routines, but prior to that, all e-mail will be inspected for viruses using Virge. Virge can be configured to use a number of different virus signature checking tools, our preference currently being the TrendMicro set. So the other two tools you need then are the trophie daemon which acts as an interface between virge and the TrendMicro scanning engine library (Look for the section headlined InterScan Messaging Security Suite.)

To stay current, regular downloads of the signature file are required. TrendMicro's website publishes these here.

For more details on how to write your sendmail routing scripts, set the appropriate file ownership on the various libraries and daemons and finally configure a secure imap server to read the e-mail store, please read on...

ComputerWorld has come out with its set of predictions for security related incidents likely to make headlines in 2004. Especially telling is their statement that "Many will begin to understand that the problem isn't with the technology, it's with the people!", something us technology people have been trying to get across for years. What makes anyone think 2004 will be any different?

Both USB ports and free access to each and every IM service do nothing to remind employees that the computing resources and data they manipulate on a daily basis belong to the company, not them. Yes, it is a people problem when these tools are used to carry confidential data into the wrong hands, but how do you reinforce this message and how do you remove temptation?
On the IM front we might see companies use internal messaging systems such Jabber and Sametime. USB ports are not so easy to control especially since these USB drives are so small and easily hidden. Perhaps some vendor will come up with a way to control allowable devices by vendor id and product code? For example, this could easily be part of the TrustedCore efforts put forth by Phoenix Technologies' cME project. (Unfortunately this project's design appears to be extremely Windows-centric and it is not clear whether any OSS can make effective use of it.)

And so, as usual, efforts are already underway to come up with technology-based solutions for what ComputerWorld so accurately pointed out, are really people problems...
Some things just don't change!

Much has been written on this subject already yet it continues to be a topic fraught with pitfalls and mired in confusion. Perhaps by describing the way NetBackup's tape writing (as implemented in bptm process) operates some of this veil can be lifted and tape drives can be made to hum more efficiently.

For each NetBackup job stream writing to tape, a bptm process is launched. Part of its launch information packet includes a description of the source of its data, i.e. the client machine, the NetBackup policy and schedule, etc. However, the first bptm process does not directly concern itself with contacting the client, instead, it forks off a child process to start listening on a predetermined TCP/IP socket for the client to contact it. The parent process meanwhile proceeds to allocate, open and otherwise prepare a tape and a tape drive to start writing the eagerly anticipated client data.
Next comes the description of how to the two pass this client data between eachother.

Anyone with more than one backup tape volume will have a need to apply labels to keep them straight. If nothing else because that is how all backup software refers to the tapes it writes and, hopefully, reads.