On 07/31/2012 02:54 AM, Linda Walsh wrote:
Wolfgang Rosenauer wrote:
I can give you examples for 32bit applications I use and need on my Linux box: Skype moneyplex (online banking) Android SDK (probably a few more less important ones)
I don't care for the megabytes some 32bit libraries use on my systems harddisk if I can run the above applications successfully. That's a very small price.
Right...and if those apps ran 1% slower (IF), due to virtualization, you probably wouldn't notice it, right?
That's assuming none of those couldn't or wouldn't be updated.... At one point Adobe was dragging their heels with Flash, but I think the threat of Flash being left behind as people moved to HTML5 based solutions might have persuaded them to be more flexible.
Still Mozilla is dragging their feet on 64 bit support on Windows -- but that didn't stop their directories from being virtualized nor the 32-bit program directories being moved.
Interesting how they didn't create the roadblocks on linux as they have on Windows...
Anyway -- I am not suggesting getting rid of 32bit support. Just putting in a 32-bit specific /usr32/{bin/lib} (only because some programs I've seen rely on ../lib or expectations...
There is a bit of a historical component you appear to be neglecting. The 64 bit stuff came after 32 bit implementations and by the time 64 bit came about on UNIX the directories had long been named without numerical components, thus /usr/lib and /usr/bin had been around for a very long time. To preserve compatibility for applications not under the control of the OS vendors the existing naming scheme remained untouched and the *64 stuff was added. This all happened long before anyone even spoke of Linux in a commercial setting. Had the GNU system broken these conventions it would not have had much success on the UNIX platforms and had Linux distributions not followed established practice we might not have had the success we have seen. Now all of this does not say things are written in stone and should not be changed, or maybe the odd cases should be fixed, but we cannot just go out and change stuff because you happen to not like certain things. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org