On Jan 21, 2007, at 8:00 PM, L. V. Lammert wrote:

On Sun, 21 Jan 2007, Brian Keefer wrote:

The company I worked for considered switching our appliance OS to a
*BSD from Linux, but in the end we decided that commercial support
was too important to ignore.

There ARE a number of vendors selling OBSD solutions, actually. One I
remember running across is LOK Technologies.

Drivers should NOT be an issue - you're building an appliance, it should
be pretty simple to picl compatible s/w.

        Lee

It's not to say there aren't vendors out there using non-Linux platforms for their appliances. I mentioned CipherTrust, but they also ran into some OS-specific issues when dealing with their DB vendor... IronPort is also based on FreeBSD, but their choice of AV engines is apparently pretty restricted. Why else would they still only have Sophos after all these years, while every other e-mail appliance vendor has multiple AV choices? My guess is they can't use Linux binary compatibility because of the extent they've hacked their kernel and FS. Maybe that's not true, but you have to wonder why they don't have McAfee or Kaspersky or Panda, etc. Borderware also uses a FreeBSD based platform, but they're a little different because they started with that for their firewall product (a reasonable choice) and extended it to e-mail later when they built a product for that. I might also point out that it took over 4 major revisions of their e-mail software to get it anywhere near stable on top of their OS.

As for the drivers... like I said, it restricts options. Our entry- level box at one point had a built-in RAID controller that was one of those pseudo-hardware controllers that was really run by a binary blob. That wouldn't have worked on OpenBSD. The motherboards we currently use have built-in nForce ethernet chips, which only became supported in 3.9. We use them for secondary/tertiary interfaces (it's basically a "free" feature that customers get). Our other options would be to select a motherboard that didn't use "blob- dependent" chipsets, or put riser cards and separate PCI cards in, or just simply ship with less features. That would either be more expense, or less value for our customers. It would also add time to our release cycle by having to test more hardware before we settle on a final design.

It might seem like a small amount of time, but a few extra combinations means a few extra weeks of QA time, and possibly engineering would have to delay coding while waiting on the final hardware config, etc... QA is actually a lengthy process in appliance design, so any added complexity in the test matrix has a negative impact on projects very quickly. It's not to say it couldn't be done: It absolutely could be. It's just that it wouldn't be zero cost, and why would we do that unless we had to?

There are lots of ways to do anything. In the end it depends what goal you're trying to achieve. If your goal is to use your favorite operating system for the project, that's certainly doable. If your goal is, hypothetically say, minimizing time to market while keeping a lid on engineering and QA costs, your OS selection might look a little different.

It's just simply a matter of using the right tool for the right job. If you're trying to do heavy-duty packet filtering VPN end-points, or routing (where most of the code is leveraging built-in tools), a *BSD is probably a good choice. If you just need a platform to load a bunch of software on top of, some of which is third-party commercial stuff, *BSD is not going to be your best choice.

As an aside, it seems like there are a fair number of us OpenBSD users here in Silicon Valley. Lots of us have been individually lobbying various hardware manufactures, most of which are headquartered in this area, to release documentation for their products. I think it might be more effective if we combine efforts and started pressing to get in-person meetings with folks in product marketing at some of these companies. If we could get 2 or 3 of us who are pretty well versed in the business side of technology to present well-reasoned arguments for why it would benefit these companies to have their hardware more widely supported, we might begin to see some cracks in the blob armor.

Is anyone else local here interested in starting an unofficial lobbying group to put together some position points as to why hardware vendors should release documentation and start trying to schedule some meetings with vendors?

Brian Keefer
www.Tumbleweed.com
"The Experts in Secure Internet Communication"

Reply via email to