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

Reply via email to