On Mon, 5 Dec 2005 14:43:18 -0500 (EST), "Joseph C. Bender" <[EMAIL PROTECTED]> wrote:
>On Sun, 4 Dec 2005, J.C. Roberts wrote: > >> On Sun, 4 Dec 2005 21:57:15 -0700, Josh Tolley <[EMAIL PROTECTED]> >> >> If someone has a viable need of Oracle products, it's in their best >> interest to get it running on OpenBSD. >> >Why? > >Going off into unsupported territory where there's probably 10 other >shops in the world doing the same thing (i.e. lack of community) will mean >chasing down lots and lots of issues yourself with very few resources to >turn to. > Communities often start with one idea and one person willing to do some work. If everyone based their decision on whether or not there are other people out there with similar interests and effort, new things would never be started. >>Sure, you're right that many people are primarily interested in getting >>supposed "support" from Oracle but forcibly drop kicking Oracle software >>onto OpenBSD will most likely allow you to find a lot of Oracle bugs. >> > Or a lot of Linux emulation bugs. Or bugs in the linux lib >packages triggered by the kernel emulation. > >Linux emulation + non-native libs + lack of documented issues = lots of >variables that are going to make it a royal pain to troubleshoot problems. > 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. 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. >>If you've got enough $ for Oracle Inc to think you're important, they >>might actually consider fixing the bugs you report. >> > If you've got that much cash to persuade them to do that, you >might as well go whole-hog and have them do a native port. And if you >have that much cash, you're probably looking at running Oracle on >$very_large_hardware that OpenBSD doesn't support yet. > Yep, you're totally right on the above. If your only goal is putting Oracle on OpenBSD in production and you have the money to pay for all the work, then you can probably make it happen. >> If Oracle software is too broken to run properly on OpenBSD and Oracle >> refuses to fix their bugs (i.e. failure to actually "support" their >> products), then you might want to reconsider your choice of software to >> see if there are other alternatives available. >> > If there's no native port, there is no running properly, period. >Even if their software was buggy, how can Oracle be reasonably expected to >fix bugs on a system that is more or less rigged with the software >equivalent of duct tape and baling wire? > 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. As for "expecting" anything from Oracle, well, even if *you* are convinced it is in their best interest to fix their bugs, it doesn't mean the decision makers at the company will be convinced. The most you can do is document your setup and findings so others can repeat your tests. 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. 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. >That being said, if OpenBSD is a requirement, then change the database to >something nice and not so bloated like PostGres. Then at least it'll >native compile. 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. 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. Kind Regards, JCR
