Linux has a rule to "never break the userland". So if you maintain your own userland(libc/gui libs, etc..) even the latest kernel will run your old software.
I forget the exact errors, but the software is simply too old.
I was also around for the tail end of the libc5 to glibc conversion, so I have definitely seen breaking change.
Yes it will.
> "I forget the exact errors, but the software is simply too old."
You're running into compatibility issues with newer libraries. Libraries do change in incompatible ways -- but the solution is simply to install the older library.
You absolutely can run 32-bit Oracle 8i on a modern kernel. The steps to do this in a nutshell (omitting a few details) are:
1) Grab a linux userland which 8i was built for (eg: RedHat7) and extract it somewhere. Use docker, create a chroot, whatever you like.
2) Enter the container/chroot and install 8i. It'll work fine, because you'll be linking the correct library versions and those libraries will still work even on a modern kernel due to the aforementioned kernel compatibility guarantees.
So you probably CAN get old Oracle databases to run on the latest kernel, but all the supporting software would be a weird mishmash of old libraries, etc.
One doesn't need to make a mess of their host OS anymore.
Containers run on your kernel and hardware natively, with a tiny bit of shims from the kernel side so it's a different root and possibly removing raw hardware access. Oracle 8i should run just as well as it would have 20 years ago, if you have all the userland libraries in order (hence putting an old distro in the container).
As long as Oracle isn't internet-facing (you can setup the container's networking however you wish, with whatever firewall rules you wish), it should be fairly safe. The modern kernel you run it on should be up to speed on the latest security patches too.