The widespread acceptance of open source continues to grow as a cost-effective alternative to traditional network deployments. Well-known projects such as Linux have proven themselves to be in the enterprise environment, helping to dispel the fear, uncertainty and doubt preceding open source implementations. In the past two years, the industry has begun to shift from a total dependence on proprietary applications to a desire for more cost-effective, scalable and collaborative solutions.

How often has OpenBSD had to fix a serious security hole? How fast did they fix it?

In the default installation? Very seldom. But fixing serious vulnerabilities in their packages (not default installation) ? Constantly. Just because a port isn't a part of the default installation, doesn't mean it's not meant to be fixed

And OpenBSD has so far fixed their holes within hours. It is typical for MOST FLOSS-projects. Security! Security! Security!

It is silly to choose compatibility over security. It is wiser to choose reduced functionality than it is to choose reduced security.

It is silly to choose compatibility over security. It is wiser to choose reduced functionality than it is to choose reduced security.

That depends entirely on the application and situation. If the actual loss in productivity due to reduced functionality overshadows the cost of a potential security breach, then you probably want to reconsider. You want to find a balance between ease of use and security, taking into account all surrounding factors.

Keep this in perspective: Packages vs. what's needed to bring up a system are entirely different concepts.

If someone wrote a program to exploit a hole in the kernel, that's one thing. If an admin installs an FTPd, for example, they do so knowing that just because it's made to be compatible with the OS, doesn't always mean it's the most up-to-date port when dealing with Free/OpenBSD, which can result in an exploited system if the package goes unchecked - and that's up to the maintainer at that point.

If the port/package maintainers are lazy, then there's a HUGE problem. If the original authors are lazy, there's an even bigger problem with the solution to fork or take over the project somewhere else.

I've not meddled with the BSD's long enough to get into who's lazy and who isn't, so I'll let this one off here, but I will re-state that the differences between OS and other software packages are clearly distinct.

What if the fix introduces another security hole? What if it breaks a major feature? I'm sorry, but except in extreme cases (say a worm thats been spreading over the net fast using the exploit), you need to properly test the fix first.

When possible, some companies do provide temporary workarounds until the fix is properly tested and released.