On Mon, Dec 05, 2005 at 08:46:55PM -0800, J.C. Roberts wrote:
> Heck, in general I agree with you. Any such effort would start off as a
> sad hack, it would be a lot of work and in the end, there might be
> nothing gained in the way of fixes since Oracle will probably just
> ignore your bug reports. I even tried to point out the fact you'll
> probably be ignored in my very first post (having enough $ for Oracle to
> think you're important).
>
> If your goal is just getting something into production, you are
> completely correct that it would take less effort to work with Oracle on
> their supported platforms or work on other database packages on OpenBSD.
> You described the smart/fast answer for getting things into production.
>
> On the other hand, if you are *already* using Oracle db's your business
> and you consider your data to be valuable, is it worth the time/money to
> run experiments to find out more about the Oracle code you are already
> running and how/if the vendor responds to your bug reports?
>
> Even if you are not important enough to Oracle get them to fix the
> problems you find, you have still gained insight from the experiments
> and testing; You've gained insight of how/if the vendor responds to your
> PR's and knowledge of bugs that exist. The insight itself is valuable in
> your decision making process of what software to run/buy and it is also
> valuable for finding your own ways to compensate for the inadequacies in
> a product you are already running.
>
> I don't want to repeat my previous mistake of assuming you do not value
> such insight, but from what you've stated, the work/cost/pain involved
> with gaining such insight through experiments is something you prefer to
> avoid. It's a perfectly reasonable stance for you and the (possibly
> overwhelming) majority of small/medium sized business out there. In
> contrast, if you happen to be responsible for something *huge* like a
> stock exchange, a mega-corp like General Electric or a on-line
> monstrosity like Amazon or eBay, extensive and continual research and
> testing is just smart risk management and is worth the pain/cost.
>
> Even if you disagree on the value of the insight gained from such
> testing, it's fairly short sighted to assume everyone on this list is
> only dealing with small stuff and they all lack the (unfortunately)
> required contacts and influence needed to get Oracle to act on problem
> reports. What might be an impossible idealistic dream to you, may be
> nothing more than a simple phone call for others. It would only take one
> such person to turn a Oracle/OpenBSD Franken-System project into
> something very useful.
>
> On average and in general you're basically right about things but still,
> there are a handful of corner cases where you're wrong. They are not
> common but they do exist.
There *is* a valid reason to test Oracle, as you pointed out. That does
not mean running Oracle on OpenBSD. Oracle on OpenBSD is most likely to
fail because the Linux emulation does not work exactly the way Oracle
wants it to work, and in the few cases where it's actually a Oracle bug
it will be nearly impossible to chase down where the bug actually is.
If you want to test Oracle, test it on a well-supported platform, as
that will cause you to find bugs that are both reasonably likely to be
in Oracle, and will be fixed in a reasonable time (in the case of
Oracle, several months to a couple of years for the most serious bugs,
according to Full-Disclosure bug reports at least... but you chose to
use it, not me).
If you want to test OpenBSD's Linux emulation, test it with a stable
open source program so that you can actually figure out what is going
wrong.
Both are valid things to test - but mixing two unknowns makes sorting
out the mess very difficult, especially because Oracle is closed source
and apparently quite picky about what it wants to run on.
Joachim
