Network Computing Misses the Mark

I really enjoy reading the free IT magazine Network Computing. However, I believe comments by NWC authors in the last two issues demonstrate some fundamental misunderstandings of open source applications and system administration. These are not earth-shattering issues, but I thought I would share them with you.

First, the 27 October 2005 issues includes an article called Open-Source Security Technology Joins Endangered List. Here are excerpts:

"For many users and vendors, network security is dependent on a collection of open-source programs that provide key capabilities, sometimes as standalone tools and sometimes as the basis for commercial products. Last month, however, the open-source status of two of those key technologies--Snort and Nessus--became threatened....

The moral is that heavy reliance on open source carries risk, and that the greatest insurance policy for open-source technology is participation by a large number of users and developers. If you're thinking of using open source, keep a close eye on what happens to both Snort and Nessus."

I would argue that open source carries much less "risk" when compared to closed applications. The fact that the code is open is the "greatest insurance policy," not "participation by a large number of users and developers." If an open source program is no longer maintained, it can be assumed by another developer. Assuming the license is truly open, that new developer can resume the project, fork it, or rebuild from scratch using the original as inspiration.

For example, Linux guru Tim Lawless started the Saint Jude project to protect the integrity of the Linux kernel, but had to abandon coding it in 2002. Last week Rodrigo Rubira Branco took over maintainership and released a new version. BASE, the replacement for the Web-based alert browser ACID, is a second example. The new version of SPADE hosted by Bleeding Snort is a third example. None of this would be possible with so-called less "risky" closed programs.

The second example of Network Computing missing the mark appeared in the following letter and response:

"I have a question concerning an application one of my consultancy clients needs that's targeted for Microsoft Data Center Server 2003, a product used to manage DPM, on Unisys 3S7000. The systems integrator is saying that 'for performance reasons,' it plans to 'modify the operating system' for the application.

It's been a long time since I've heard of any vendor advocating modification of a native OS to boost performance or achieve goals not supported by the OS. I've been all over Microsoft's OEM partner site and haven't read anything about using Data Center Server as an OEM product. Not even its predecessor, Data Center Server 2000, was ever available as a shrinkwrapped product; you had to have Microsoft services to implement it.

Have you ever heard of any vendor wanting to tweak the Windows kernel in order to support its application? Sounds risky...

Don MacVittie replies: Larry, your instincts are dead-on. Even in the Linux world, tweaking the OS for the application layer is generally considered taboo. There's just too much that can go wrong.

Are you sure the vendor is talking about making code changes to the kernel? Maybe what it has in mind is custom drivers, which are more acceptable, or a custom build, which is relatively common for OEMs.

If the vendor really does want to modify the kernel, you should tell your client to run away from it as fast as it can. There are enough good products out there to handle high-volume backups and replication without having to resort to such a drastic measure."

Good grief. "Even in the Linux world, tweaking the OS for the application layer is generally considered taboo. There's just too much that can go wrong." Like what, better performance? I do not know if it is possible for end users to make any modifications to the Windows kernel, perhaps via a sysctl mechanism as found in BSD. I do not fault the NWC writer for advising users to stay away from Windows kernel tweaks.

Linux and BSD are completely different beasts. I find the power to alter the kernel to be an advantage, not voodoo. In production I make few kernel customizations on BSD not because I am scared and need to "run away." I only make the customizations with which I am familiar, like adding support for IPSec or NAT. If I encountered a problem that could be addressed by customizing the kernel, I would take full advantage of the control that an open source OS provides.

What are your thoughts on these issues?