Donald J. Ankney wrote:
The cheapest solution I could find for a fibre-channel SAN was Apple's
XSAN.
Fine, but wasn't your requirements here the cheapest solutions, not the
platform on witch it run? I don't know that, only you do. But may be
there was and is a very nice solutions working on OpenBSD, but that was
just more expensive and that you couldn't pick. Again I don't know, but
you justify it by the cheapest, not what's good for the job. Again, I
use what's supported, not what's the cheapest and then asking to have it
supported then.
That's the difference.
If I'm running an Open Source product (which is most of the time), I
generally compile it on OpenBSD. This is where OpenBSD is strong.
Sometimes, though, my needs push me towards a commercial solution
(XSan, VMWare, etc). I'm not going to try and implement it in an
unsupported environment; even if the problem is in the product code,
they aren't even going to take a bug report from me if I'm running
OpenBSD.
That's fair, but again, wasn't that driven by the cheapest solutions,
not what's right for the job. I don't know and you don't need to answer
it either. I am not saying you are wrong, I am only saying that going
from Vendor support to cheapest solutions change the "what's right for
the job" argument. Not that your choice is wrong. Only that may be the
argument is twisted here, that's all. If what you need is not supported
on OpenBSD, then yes use something else, but if the choice of hardware
you elect to use is based on the cheapest solutions and that doesn't run
well on OpenBSD, is that make OpenBSD the problem here or the choice of
the hardware to start with? Only you know that answer, but that's also
part of what's right for the job. Only depend on what you define right
for the job spec here.
I'm also going to agree that the "bazaar" development practice produces
stabler, more secure software. Ideally, I'd have the resources to
develop my own solutions when I can't find an appropriate open source
product, but it doesn't always work that way and I end up recommending
a software purchase.
I am not arguing this again. I simply said that I have no problem with
what OpenBSD provide me for what it has and that it is supported very
well. If what you need is default in OpenBSD, great use it, if not then
use something else. Again, I refer to the starting point of using Vendor
as a stand for the choices. Some may use ssh.com for their ssh solutions
and that's fine. But none really could argue that they use it because of
Vendor support. Well, I guess they could, but it is really valid? Again
the right choice for the job. For my job OpenSSH is great and no need
for ssh.com to be in the picture here. That's my choice.
Again, I only argue about the use of design OpenBSD choice, like CARP
instead of "HSRP and VRRP." One would argue that they will pick "HSRP
and VRRP." over CARP because of Vendor support. I guess I would argue
the same then. I would pick CARP in a hart beat because of Vendor
support! (:> Plus it works a lot faster and better, what's wrong with that?
Same thing, if I want to use OpenBSD as internal routers on my network,
then I need to change the use of ISIS to OSPF. If I don't want to do
that, then I don't use OpenBSD for that. So, my choice are switch to
OSPF and use OpenBSD if that's more important to me to have support from
OpenBSD for my internal routers then Cisco for my internal routers, or
stick with ISIS for internal routers and pay Cisco SmartNet for that
then. The choice is mine to make for what I consider the right tools for
the job based on the impact it has on my setup. But I have the choice.
I think you're misunderstanding me here -- I wasn't ever claiming that
OpenBSD lacks support as on OS. I've never had trouble finding answers
when I need them.
If I did, I apologizes for that, but I don't think I said that you
didn't pick OpenBSD because OpenBSD doesn't support it own stuff. I
stated the choice because of the "Vendor support" aspect of it that is
for me a none argument really. But again, that's my point of view that
no one need to agree with really, but never the less if one sit back and
look at real life example may find it true however.
Commercial products that may be able to run on
OpenBSD are generally unsupported.
I hope you are not saying that OpenBSD should support your commercial
elected choice right? That's liek saying OpenSSH should support IBM in
their own customers ssh contract where they pocket the money, but
OpenSSH should fix the problem IBM customers have with IBM product on
IBM support contract!
I am sure you are not saying that for sure!
Even many open source product won't
necessarily take bug reports if it's running in a BSD instead of on a
"supported" kernel.
Nor should they. If anyone elect to do something not supported because
they want to, they sure have the choice to do that. That's the opne
source choice, but in no case shoudl they ever have the right to come
back and say, hey I use this, but you need to support me on that.
Again, I am sure you are not saying that either.
Again, let me stress that nothing is wrong with OpenBSD. I love
OpenBSD. The problem is in a marketplace that values features above
security/stability and thinks time to market is more important than
writing clean, portable code.
And that's your choice, but not mine. No argement from me on that.
Anyone that prefer features, even unused most of the time are welcome to
spend their money where ever they see fit. But personally and for may
own business, I WILL never pick features over security and stability!
Sorry, I need to sleep at night for what ever time I can when I can!
Again, each one their own choices.
The right tools fo the job. Some like features, then go for it. That's
why there is choices. Isn't great! Each one can take what they want in
the end.
But when arguing, stay true to the idea at hand and what's the choice
and requirements for the elected product. Changing the playing field
along the way to justify what to use or not to use is wrong. I think it
is anyway,. but YMMV.
Thanks
