[opensuse-factory] Re: Why bin & no bin64? => lets fix lib64=>lib, bin(32),lib(32)=>/usr32/{bin,lib}
Linda Walsh wrote:
Nelson Marques wrote:
Ever heard of FHS? It's stands for Filesystem Hierarchy Standard.
Enjoy the reading :)
It is based on really screwed up reasoning. Why was it accepted?
Regardless, Suse doesn't follow it now, so why not move ahead with a more soundly reasoned solution.
Seems a smart solution would be to use a separate file-system namespace with everything but the bin & lib directories being the same between 32&64 bit.
Would provid transparency. Their rational .. that lib(X) is architecture dependent, also applies to /bin, yet they don't apply the same reasoning.
... more specifically under specific options, they also say: lib<qual> Alternate format essential shared libraries (optional)
"Lib<qual>" is for an alternate format. Alternate to what? I would assert alternate format doesn't mean native format. And that on a X64 machine running an X64 kernel where x32 compatibility is *optional*, that it is 32-bit dirs that are optional. So the document is internally inconsistent besides being.
========= I think having a smart loader that virtualizes the arch-dependent dirs.
To make it arch, blind, create a /usr64/{bin,lib}, then on any given machine, /usr/{bin,lib} can be mounts/links to the native binaries (/usr64 or /usr32...)...
Rational -- their rational was based on 8 year old data when x86-32 packages out numbered x86-64 packages. Clearly that doesn't apply on a modern x86-64 bit system -- where it's better than 3:1 64-bit (linux certainly has taken the lead on this). Existing 32 bit binaries would almost never work on a 64 bit system -- you would need to have the same libraries installed..
Does suse support taking 32bit binaries from 2004 and installing them on a 2012-suse12.1 system?
If not, the justification for this is negated.
What they don't mention is that existing programs are rebuilt, often from sources, and will build with the defaults for that platform. That being the case, it would require modification of those programs to work if their lib path wasn't "/usr/lib".
Supporting non-recompiled binaries from 8 or more years prior, I don't think has ever been supported. What were they thinking?
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 7/28/2012 4:40 PM, Linda Walsh wrote:
Linda Walsh wrote:
Nelson Marques wrote:
Ever heard of FHS? It's stands for Filesystem Hierarchy Standard.
Enjoy the reading :)
It is based on really screwed up reasoning. Why was it accepted?
Regardless, Suse doesn't follow it now, so why not move ahead with a more soundly reasoned solution.
Seems a smart solution would be to use a separate file-system namespace with everything but the bin & lib directories being the same between 32&64 bit.
Would provid transparency. Their rational .. that lib(X) is architecture dependent, also applies to /bin, yet they don't apply the same reasoning.
... more specifically under specific options, they also say: lib<qual> Alternate format essential shared libraries (optional)
"Lib<qual>" is for an alternate format. Alternate to what? I would assert alternate format doesn't mean native format. And that on a X64 machine running an X64 kernel where x32 compatibility is *optional*, that it is 32-bit dirs that are optional. So the document is internally inconsistent besides being.
========= I think having a smart loader that virtualizes the arch-dependent dirs.
To make it arch, blind, create a /usr64/{bin,lib}, then on any given machine, /usr/{bin,lib} can be mounts/links to the native binaries (/usr64 or /usr32...)...
Rational -- their rational was based on 8 year old data when x86-32 packages out numbered x86-64 packages. Clearly that doesn't apply on a modern x86-64 bit system -- where it's better than 3:1 64-bit (linux certainly has taken the lead on this). Existing 32 bit binaries would almost never work on a 64 bit system -- you would need to have the same libraries installed..
Does suse support taking 32bit binaries from 2004 and installing them on a 2012-suse12.1 system?
If not, the justification for this is negated.
What they don't mention is that existing programs are rebuilt, often from sources, and will build with the defaults for that platform. That being the case, it would require modification of those programs to work if their lib path wasn't "/usr/lib".
Supporting non-recompiled binaries from 8 or more years prior, I don't think has ever been supported. What were they thinking?
It is supported because commercial binaries cost a lot, are not practically replaceable, and are not recompilable. 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. If I couldn't do that, I couldn't use suse. There was a one time unique event (so far) that was outside suse's control where a kernel/libc interface change meant even statically linked bins couldn't go past a certain version. It wasn't just libc5 vs libc6. That was years ago by now. So perfect 100% backwards compatibility forever isn't possible, but that doesn't mean it isn't important. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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. I remember the build people having problems if they had 32 and 64-bit versions of things loaded and tried to build at the same time, but if the 32-bit stuff automatically used a 32-bit root, wouldn't those go away too? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2012-07-30 20:00, 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?
Unreal Tournament 99.
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.
You could indeed. You do not even need the chroot, I think. IIRC, /emul-linux or so is a special directory for that kind of thing as well. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jul 30, 2012 at 08:32:08PM +0200, Jan Engelhardt wrote:
On Monday 2012-07-30 20:00, 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?
Unreal Tournament 99.
And any Wine Win32 based thing.
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.
You could indeed. You do not even need the chroot, I think. IIRC, /emul-linux or so is a special directory for that kind of thing as well.
Or just /usr/lib ... :) Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Marcus Meissner wrote:
On Mon, Jul 30, 2012 at 08:32:08PM +0200, Jan Engelhardt wrote:
On Monday 2012-07-30 20:00, 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? [that couldn't be run as below, specifically: No virtualization needed -- at full speed and w/full access to graphical HW (thinking Wine based graphix games)..] Why wouldn't that work? Unreal Tournament 99.
And any Wine Win32 based thing.
At worst, you could run the win32 based unreal..., but I'd think simply using /emul-linux as mentioned below would work just as well... So far you are just proving the point. There are just as strong reasons to make /usr/lib be 64bit by default, and have the 32-bit (bins+libs use /usr32 -- that can be easily mapped into an exec environment for non-recompilable binaries. As it stands, the onus is on the majority (80%) of the 64bit utils to have to be changed to adapt to our 64 bit machines -- even though the source references "/usr/bin /usr/lib", and should find such references to be "native" locations... Anything else is madness!....let it be incumbent on those binaries that are non native, to have a non-native environment setup for them. Certainly the kernel takes this approach with ia32 support having to be specifically compiled in for the optional 32-bit binaries to work. Why not follow the example of the kernel and expect that you are compiling on / for the native environment unless told otherwise -- then provisions can be made? Why is my boot package not x86_64? (I know they are similar boot processes, but looking at my boot log: klogd 1.4.1, log source = ksyslog started. [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.2.21-Ish-Van (law@Ishtar) (gcc version 4.6.2 (SUS E Linux) ) #1 SMP PREEMPT Fri Jun 29 23:58:37 PDT 2012 [ 0.000000] Command line: auto BOOT_IMAGE=3221-Ish-Van rw root=/dev/sdc1 root =/dev/sdc1 showopts console=ttyS0,115200n8 console=tty0 elevator=cfq pcie_aspm=f orce pcie_ports=native delayaccnt [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 00000000000a0000 (usable) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf379000 (usable) --- the kernel looks like it knows at the first BIOS entry map, and certainly by the 2nd, it knows it has more than 32bit address space. So the kernel boots up in 64-bit mode. Why not a x86_64 bit package? (below kept for reference if needed..., no new content after this point)...
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. ***DELETED TEXT INSERTED ABOVE those who reply without context...*** You could indeed. You do not even need the chroot, I think. IIRC, /emul-linux or so is a special directory for that kind of thing as well.
Or just /usr/lib ... :)
Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2012-07-31 00:31, Linda Walsh wrote:
Why wouldn't that work? [What prog that won't be provided as 64-bit is there?] Unreal Tournament 99. [Linux version] And any Wine Win32 based thing.
At worst, you could run the win32 based unreal..., but I'd think simply using /emul-linux as mentioned below would work just as well...
So far you are just proving the point. There are just as strong reasons to make /usr/lib be 64bit by default, and have the 32-bit (bins+libs use /usr32 -- that can be easily mapped into an exec environment for non-recompilable binaries.
This idiotic idea has been proposed before, and to death (FATE#308372); Debian, being the originator, even implemented it, and fell on its face flat, having a complete mess. (But at least they also found a great way out again, see http://wiki.debian.org/Multiarch/ )
Why is my boot package not x86_64?
Because grub-0.97 does not strictly depend on x86_64 instructions.
So the kernel boots up in 64-bit mode. Why not a x86_64 bit package?
The kernel is a x86_64-type package, if you installed the right architecture. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
participants (4)
-
Brian K. White -
Jan Engelhardt -
Linda Walsh -
Marcus Meissner