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"
