On 7/30/2012 2:00 PM, Linda Walsh wrote:
Brian K. White wrote:
It is supported because commercial binaries cost a lot, are not practically replaceable, and are not recompilable.
Agreed. Can you name 1 that doesn't produce 64-bit compatible binaries today?
I routinely install such old 32bit-only binaries on new 64bit systems, from several different vendors, and all I need for them to work is matching 32bit libraries.
Is there anything that would prevent running the small number of those in a chroot env where only the 32-bit binaries are subbed in? -- or a VM if needed? Using namespaces, a 32-bit binary could run with it's 32-bit binaries in the normal places, and all the rest of your files in the normal place as well. No virtualization needed -- at full speed and w/full access to graphical HW (thinking Wine based graphix games)... Why wouldn't that work?
Seriously, where's the problem? Is it just a matter of fixing the packaging? Certainly investing some time in such a split/cleanup would be worth it.
The main reason I wouldn't do that is because I don't have any problem. My stuff all works fine, and it's not flash or games, it's all back end expensive work stuff. I didn't write them, and they come from several different vendors, mostly vendors that used to support SCO and Sun, you know, UNIX. If I had written it, or if it all came from one source, I might be willing to contemplate at least the possibility that that one source is a fluke and not a valid support target. But since that's not the case; If you have some sort of problem, I suggest you figure out whatever work-arounds you need for your stuff and leave everyone else out of it. And if you can identify some actual problem that is, or could be of general interest, articulate the problem and the proposed solution, more clearly. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org