On Mon, 5 Dec 2005 21:24:55 -0500 (EST), "Joseph C. Bender" <[EMAIL PROTECTED]> wrote:
>On Mon, 5 Dec 2005, J.C. Roberts wrote: > >> You certainly have a valid point when it comes to doing useful >> production work with Oracle on OpenBSD but from what you've written, it >> seems like you do not value the "bug finding" process all that much. >> > You could not be more wrong. Do *not* presume that you may >assume what I do or do not value. > Sorry about that. I'll try not to do it again. :-) >> My >> opinion is the exact opposite; the main reason for attempting such a >> configuration *_is_* to find the bugs and hopefully fix them. Sure, >> you're right it's a royal pain, but if no one does the work, it never >> gets done. >> > Yes, but there's fixing bugs you can get at, and there's the >banging of one's head against a brick wall created from running a closed >source package in an *emulated* environment. > >> When you're starting off, duct tape and bailing wire are your best >> friends mainly because there is no other way to get going. You can kind >> of think of it as boot strapping. It's not going to happen over night or >> anytime soon. >> > You're not getting it. It's not bootstrapping, it's a gross, >ugly, nasty hack. This is not making a port work, this is kludging >something into functioning when a much better effort could be made on >other platforms or by using other database packages. > >> In a nutshell, it comes down to your goals and your time frame. If you >> want the Oracle code you run to be more reliable, robust and secure on >> "$very_large_hardware that OpenBSD doesn't support yet" just using >> OpenBSD to find some bugs could be a worthwhile experiment even if you >> never actually use OBSD/Oracle in production. >> > >This only works for a native port! You're not running Oracle on OpenBSD, >you're running Oracle on what Oracle thinks is some wierd LINUX. > >> A lot of companies would consider such efforts to be a waste of >> time/money but as you can see by this thread, there are some people who >> think the task might be a fun or interesting hack... -You can view it as >> the difference between those people who follow the warning on the >> sticker "Warranty Void If Removed" and those people who are more >> interested in learning what can be learned. >> > And some people think drilling holes in their head leads to some >deep inner wisdom. This does not make it a good idea. If someone wants >to use *linux emulation* to run Oracle on OpenBSD and think it's doing >some good, they can go right ahead. > >I've been there and done that with trying to hack evil crap into >working in places it shouldn't, and all I've learned is that it leads >to nothing but a ton of pain. Some people need object lessons in said >pain before it sinks in. Their call, I guess. I'd rather work on >something more useful or interesting. > >> Yes. And I think we will both agree the decision of what to use in >> production really comes down to the requirements. On the other hand, I >> think if a company really values the data they store in their production >> Oracle db's, financing a bit of experimentation to find/fix bugs is in >> the best interest of company long term. >> > Again, you think this will lead to bugfixes. I marvel at your raw >idealism. > >> I think the best way you could understand my view on the whole >> Oracle/OBSD thing is by analogy... >> >> The OpenBSD port to the SGI-O2 platform has been ongoing for some time >> and even after almost 2 years of work, the port is still "incomplete" >> since we don't have an X server. None the less, the O2 porting effort >> has allowed new types and classes of bugs to be found mainly because the >> bugs have not shown up on other architectures. Fixing the newly >> discovered bugs benefits all the supported architectures. Since you >> don't have X, you can't use your O2 as a "production desktop" yet but >> the porting effort has still been beneficial to the project as a whole, >> including all the folks who only use other archs. >> > Your analogy is flawed. > >The discovered bugs are actively used by the OpenBSD devs to fix. As you >yourself have even asserted, there's a pretty good chance that Oracle >would probably ignore the bug reports, and given that it'd be coming from >an environment that is nowhere near the intended platforms that they coded >for, I wouldn't blame them. 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. Kind Regards, JCR
