On Apr 5, 2006, at 3:30 PM, Daniel Ouellet wrote:
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.
If you're working for an employer where cost (both initial and TCO)
are not part of the solution criteria, are they hiring?
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.
I think we're approaching things from very different positions. To
me, an operating system doesn't provide solutions. It's the platform
on which solutions are implemented. Judging from your examples, your
job is focused far more on switching and routing than mine is.
OpenBSD does ship with a fairly complete toolkit for those tasks.
I'm a systems administrator, so my outlook is toward data access/
storage/security and end-user experience. An OS shouldn't ship with
those sorts of tools -- if I wanted a that sort of mess, I'd use RedHat.
I'm not looking of OS or hardware-level support. When I implement a
solution, it either needs to be simple enough to debug myself if I
find problems or I need to have a mechanism to report bugs to the
developers with a reasonable expectation that they will be fixed in
the source. The latter is especially critical when the only solution
I can find is a closed-source solution. I'd rather not use closed-
source ever, but sometimes that's just how the cards come up.
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.
What you call features, I call end-user requirements.
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.
Not all tasks have the same criteria. It's not changing the playing
field, it's evaluating each task/job as it comes and setting the
solution criteria appropriately. My bottom line can't be
quantitatively measured by network efficiency. I have 5 subnets full
of end-users sitting at Windows and Mac workstations trying to do
whatever it is they do. My bottom line is how well I can build/manage/
design services that meet their needs. Again, I think we have very
different jobs.
-- Don
