[opensuse] Re: Why bin & no bin64? => lets fix lib64=>lib, bin(32),lib(32)=>/usr32/{bin,lib}
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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Linda Walsh - 12:25 28.07.12 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.
AFAIK, we follow it, do you have any counterexample?
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.
Check Debian multiarch[1] proposal which is IMHO quite a nice idea, although I would not argue for usr-merge Fedora does.
Would provid transparency. Their rational .. that lib(X) is architecture dependent, also applies to /bin, yet they don't apply the same reasoning.
You might need 32-bit and 64-bit libraries at the same time as you may have 32bit program requiring it and different 64bit one at the same time. On the other hand having both 32bit version and 64bit version of program doesn't really make huge sense apart from few minor specialized cases.
...
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...)...
Debian multiarch is much better/universal proposal ;-) And also cleaner.
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?
I don't see any problem with that as long as they are statically linked or have relevant 32bit libraries available with unchanged API/ABI (which might be quite difficult) ;-)
...
Supporting non-recompiled binaries from 8 or more years prior, I don't think has ever been supported. What were they thinking?
Even nowadays some companies produce closed source 32bits only applications. Or closed source soft-float only binaries ;-) [1] http://wiki.debian.org/Multiarch/TheCaseForMultiarch -- Michal HRUSECKY SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Michal Hrusecky wrote:
Linda Walsh - 12:25 28.07.12 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.
AFAIK, we follow it, do you have any counterexample?
I gave a bunch of statistics 35% of the binaries in bin are 64bit. bin contains only 25% of the overall packages, so only 20% of the libraries in lib & lib64 are 32-bit. The rest are 64-bit. The original reasoning was continued and widespread usage of 32-bit programs. However, If I look at what those 32-bit programs are supporting -- in bin: master-boot-code-1.22-7.1.2.i586 sas_ir_snmp-3.17-1092.i386 sas_snmp-3.17-1092.i386 sas_snmp-3.17-1092.i386 sas_ir_snmp-3.17-1092.i386 sas_ir_snmp-3.17-1092.i386 ---- Suse's boot code. and some 3rd party snmp HW drivers that I don't run or need. So we have 20% of the libraries reserving 65% of /usr/lib for 1 suse program? Um... is that a good enough counter example?
You might need 32-bit and 64-bit libraries at the same time as you may have 32bit program requiring it and different 64bit one at the same time. On the other hand having both 32bit version and 64bit version of program doesn't really make huge sense apart from few minor specialized cases.
---- Can't think of too many examples, most are because they haven't gotten a new version out yet. Can you think of a counter-example? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Linda Walsh - 11:08 30.07.12 wrote:
Michal Hrusecky wrote:
Linda Walsh - 12:25 28.07.12 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.
AFAIK, we follow it, do you have any counterexample?
I gave a bunch of statistics 35% of the binaries in bin are 64bit. bin contains only 25% of the overall packages, so only 20% of the libraries in lib & lib64 are 32-bit. The rest are 64-bit. The original reasoning was continued and widespread usage of 32-bit programs.
I was asking for examples where we do not follow FHS ;-) -- Michal HRUSECKY SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Michal Hrusecky wrote:
Linda Walsh - 11:08 30.07.12 wrote:
Michal Hrusecky wrote:
Linda Walsh - 12:25 28.07.12 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. AFAIK, we follow it, do you have any counterexample?
I gave a bunch of statistics 35% of the binaries in bin are 64bit. bin contains only 25% of the overall packages, so only 20% of the libraries in lib & lib64 are 32-bit. The rest are 64-bit. The original reasoning was continued and widespread usage of 32-bit programs.
I was asking for examples where we do not follow FHS ;-) By putting 64-bit native programs in the native /usr/lib directory.
The FHS says they belong in the /lib64 directory Why the intermix 32 and 64 bit programs though is a bit odd... I doubt that standard 64-bit programs are supposed to link with /usr/lib either, though most do -- I'll often see messages about the linking ignoring incompatible libraries in lib -- a 64-bit build should look in the 64-bit dirs first... The problem, is that the majority of programs have to be modified to fit the FHS, while the minority of legacy programs that would work equally well in a 32-bit root, push the native apps out of place. This despite their putting IA64 libraries in /usr/lib (despite Intel including i386) compatible options with their IA64's .. But it wasn't native there either. So why x86_64? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
[31.07.2012 14:17] [Linda Walsh]:
Michal Hrusecky wrote:
Linda Walsh - 11:08 30.07.12 wrote:
Michal Hrusecky wrote:
Linda Walsh - 12:25 28.07.12 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. AFAIK, we follow it, do you have any counterexample?
I gave a bunch of statistics 35% of the binaries in bin are 64bit. bin contains only 25% of the overall packages, so only 20% of the libraries in lib & lib64 are 32-bit. The rest are 64-bit. The original reasoning was continued and widespread usage of 32-bit programs.
I was asking for examples where we do not follow FHS ;-) By putting 64-bit native programs in the native /usr/lib directory.
Yes, and a lot of them: for DAT in /usr/lib/*; do file $DAT >> usrlib.txt; done grep -c '64-bit' usrlib.txt 19 ls -l /usr/lib | wc -l 806 19 of 806 files are in the wrong directory! openSUSE violates FHS! Alarm!
Why the intermix 32 and 64 bit programs though is a bit odd...
One of them is /usr/lib/chrome_sandbox. Maybe you should ask google.com why they mix. Just my 2¢ Werner -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Werner Flamme wrote: 64-bit native programs in the native /usr/lib directory.
Yes, and a lot of them: for DAT in /usr/lib/*; do file $DAT >> usrlib.txt; done grep -c '64-bit' usrlib.txt 19 ls -l /usr/lib | wc -l 806
You might check a few other stats:
file /usr/lib/* >/tmp/usrlib.txt wc /tmp/usrlib.txt 1203 10319 151426 /tmp/usrlib.txt grep -c '32-bit' /tmp/usrlib.txt 389 grep -c '64-bit' /tmp/usrlib.txt 75 rpm -qf /usr/lib/*|sort|uniq>/tmp/usrlib_rpms.txt wc /tmp/usrlib_rpms.txt 612 1326 24258 /tmp/usrlib_rpms.txt grep -P '32bit|\.\d86' /tmp/usrlib_rpms.txt |wc 292 292 11514 grep x86_64 /tmp/usrlib_rpms.txt |wc 474 474 17470 pcalc 507-329 = 182
182/612 packages .... seems like alot more than 19 files... But this is for a server, not a desktop w/windows compat For the /usr/lib64 dir: rpm -qf /usr/lib64/*|sort|uniq>/tmp/usrlib64_rpms.txt
grep x86_64 /tmp/usrlib64_rpms.txt |wc 1442 1442 48067
And the above 32-bit libraries support how many 32-bit packages in /usr/bin? rpm -qf /usr/bin/*|sort|uniq|grep -P '32bit|\.\d86'|wc 0 0 0 Just my 2 ¢ I don't have chrome on my box... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/28/2012 02:25 PM, 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?
Well, It was an 'attempt' to fix the "squirrel it away wherever you fell like it" syndrome... The reasoning behind it was well founded from that standpoint. The primary purpose was to foster a cross-distribution set of filesystem locations that software developers could rely on when developing code. Back in the days of "Nothing runs on Linux -- all the games are on Win 3.0". While well intentioned, it was never fully embraced across the distros. Each more-or-less adopted there own version of it, deciding what they wanted in /lib, whether they wanted to use a and alternate /lib64 designation, etc.. So in the end, it failed to accomplish its intended purpose. Instead standardizing on names and locations, we invented GNU autoconf, libtool, etc. What really miffs me more than the standard itself are all the distros still don't have the same sense of what goes in the various parts of the hierarchy and some have gone to eliminating entire parts of the hierarchy and simply using symlink for some of the base directories. So I see is not as a "Why was it accepted?" question, but more of a "Why wasn't it ever accepted?" question. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
David C. Rankin -
Linda Walsh -
Michal Hrusecky -
Werner Flamme