Hello all,
I am running CentOS 5.6 64 bit.
When running "yum -y install ncurses-devel", I expect that only ncurses 64 bit version will be installed.
However, actually both i386 and x64 are installed, that made me unhappy :)
ncurses-devel-5.5-24.20060715.i386.rpm ncurses-devel-5.5-24.20060715.x86_64.rpm
Is there anything worng here?
Regards,
Nguyen Vu Hung.
Hi,
On Wednesday, July 13, 2011 at 1:50 PM, Nguyen Vu Hung (VNC) wrote:
Hello all,
I am running CentOS 5.6 64 bit.
When running "yum -y install ncurses-devel", I expect that only ncurses 64 bit version will be installed.
Try: yum -y install ncurses-devel.x86_64
Or, add “exclude=*.i?86” in your /etc/yum.conf before running the same command you did earlier.
HTH,
(2011/07/13 12:07), Edo wrote:
Hi,
On Wednesday, July 13, 2011 at 1:50 PM, Nguyen Vu Hung (VNC) wrote:
Hello all,
I am running CentOS 5.6 64 bit.
When running "yum -y install ncurses-devel", I expect that only ncurses 64 bit version will be installed.
Try: yum -y install ncurses-devel.x86_64
Or, add “exclude=*.i?86” in your /etc/yum.conf before running the same command you did earlier.
This is what I did and observed.
1. Add "exclude = *.i?86" to /etc/yum.conf cf. http://wiki.centos.org/FAQ/General#head-357346ff0bf7c14b0849c3bcce39677aaca5...
2. Query yum search ncurses-devel Query result: Two ncurses-devel are *still* there!
3. Try to uninstall rpm -e `rpm -q --queryformat "%{name}.%{arch}\n" ncurses-devel` It works like charm, "rpm -qa | grep ncurses-devel"
4. Reinstall sudo yum -y install ncurses-devel Well, this time only 64 bit one was installed. -> ncurses-devel-5.5-24.20060715.x86_64.rpm
# 5. Other "duplicated" rpms # rpm -qa --queryformat='%{n}-%{v}-%{r}.%{arch}\n' | grep '.i[3456]86$' | sort
Thank you,
(2011/07/13 12:07), Edo wrote:
.... “exclude=*.i?86” in your /etc/yum.conf
Like many, I dislike both i386 and x64 packages being installed on my x64 machines.
However, is there a potential danger than in installing only x64 packages, one of the required files might be available only in i386 format and thus detrimentally excluded ?
Some illuminating clarity is welcome.
On 7/13/2011 9:54 AM, Always Learning wrote:
(2011/07/13 12:07), Edo wrote:
.... “exclude=*.i?86” in your /etc/yum.conf
Like many, I dislike both i386 and x64 packages being installed on my x64 machines.
However, is there a potential danger than in installing only x64 packages, one of the required files might be available only in i386 format and thus detrimentally excluded ?
Some illuminating clarity is welcome.
Note that some 3rd party binaries programs may expect/require 32 bit libs to be present - vmware server, for example.
On Wed, 2011-07-13 at 10:02 -0500, Les Mikesell wrote:
On 7/13/2011 9:54 AM, Always Learning wrote:
(2011/07/13 12:07), Edo wrote:
.... “exclude=*.i?86” in your /etc/yum.conf
Like many, I dislike both i386 and x64 packages being installed on my x64 machines.
However, is there a potential danger than in installing only x64 packages, one of the required files might be available only in i386 format and thus detrimentally excluded ?
Some illuminating clarity is welcome.
Note that some 3rd party binaries programs may expect/require 32 bit libs to be present - vmware server, for example.
And Skype.
B.J.
CentOS Linux release 6.0 (Final)
In yum.conf you can try:
multilib_policy=best
With this yum priorize the packages based on your architecture, but dont exclude the all the i386 packages if you have a x64 system.
On 13-07-2011 12:16, B.J. McClure wrote:
On Wed, 2011-07-13 at 10:02 -0500, Les Mikesell wrote:
On 7/13/2011 9:54 AM, Always Learning wrote:
(2011/07/13 12:07), Edo wrote:
.... “exclude=*.i?86” in your /etc/yum.conf
Like many, I dislike both i386 and x64 packages being installed on my x64 machines.
However, is there a potential danger than in installing only x64 packages, one of the required files might be available only in i386 format and thus detrimentally excluded ?
Some illuminating clarity is welcome.
Note that some 3rd party binaries programs may expect/require 32 bit libs to be present - vmware server, for example.
And Skype.
B.J.
CentOS Linux release 6.0 (Final)
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
At Wed, 13 Jul 2011 15:54:18 +0100 CentOS mailing list centos@centos.org wrote:
(2011/07/13 12:07), Edo wrote:
.... “exclude=*.i?86” in your /etc/yum.conf
Like many, I dislike both i386 and x64 packages being installed on my x64 machines.
However, is there a potential danger than in installing only x64 packages, one of the required files might be available only in i386 format and thus detrimentally excluded ?
If there is some program you want or need and use yum to install it, yum will install any needed dependencies. If the package needs an i386 package, yum will install it or if you have an "exclude=*.i?86", yum will complain that there are unresolved dependencies (and tell you what they are). You can then edit /etc/yum.conf to make whatever exceptions are needed.
I don't think any of the core packages are dependent on any i386 packages.
Some illuminating clarity is welcome.
Edo wrote:
Hi,
On Wednesday, July 13, 2011 at 1:50 PM, Nguyen Vu Hung (VNC) wrote:
Hello all,
I am running CentOS 5.6 64 bit.
When running "yum -y install ncurses-devel", I expect that only ncurses 64 bit version will be installed.
Try: yum -y install ncurses-devel.x86_64
Or, add “exclude=*.i?86” in your /etc/yum.conf before running the same command you did earlier.
HTH,
RHEL/CentOS always installs both 32-bit and 64-bit libraries, that is the way Red Hat wanted it, so Applications designed only as 32-bit can run without any modification on 64-bit system. If you check other packages, you will see many have 32-bit counterparts.
This is normal behavior without any repercussions, so unless you intend to remove all 32-bit libraries from your system, I recommend to go ahead and install both 32-bit and 64-bit packages.
Ljubomir
Hi,
On Wednesday, July 13, 2011 at 4:00 PM, office@plnet.rs wrote:
RHEL/CentOS always installs both 32-bit and 64-bit libraries, that is the way Red Hat wanted it, so Applications designed only as 32-bit can run without any modification on 64-bit system. If you check other packages, you will see many have 32-bit counterparts.
This is normal behavior without any repercussions, so unless you intend to remove all 32-bit libraries from your system, I recommend to go ahead and install both 32-bit and 64-bit packages.
That depends on what system you’re building.
I haven’t used any 32-bit systems for many years now. I don’t have any need for them so I don’t install them. So, unless it’s absolutely needed, I suggest deleting them all.
On 07/13/11 12:57 AM, Edo wrote:
I haven’t used any 32-bit systems for many years now. I don’t have any need for them so I don’t install them. So, unless it’s absolutely needed, I suggest deleting them all.
for many things, 32bit code is more compact and runs faster than 64bit code (primarily because the code is smaller, so it requires fewer fetches, more code fits in the cache, etc). 64 bit OS's totally compatible with 32bit applications. of course, if a process needs more than a couple gigabytes of address space, then 64bit is a no-brainer, but there's really not that many applications which need that sort of memory.
On Wed, 13 Jul 2011, John R Pierce wrote:
for many things, 32bit code is more compact and runs faster than 64bit code (primarily because the code is smaller, so it requires fewer fetches, more code fits in the cache, etc). 64 bit OS's totally compatible with 32bit applications. of course, if a process needs more than a couple gigabytes of address space, then 64bit is a no-brainer, but there's really not that many applications which need that sort of memory.
Is that generally true? I thought running in 64bit got you access to twice as many registers and that generally you'd expect better performance from x86_64 code not worse. While pointers would be doubled in size, most of your memory consumption would boil down to base types that'd be of the same size.
jh
At Wed, 13 Jul 2011 09:17:55 +0100 (BST) CentOS mailing list centos@centos.org wrote:
On Wed, 13 Jul 2011, John R Pierce wrote:
for many things, 32bit code is more compact and runs faster than 64bit code (primarily because the code is smaller, so it requires fewer fetches, more code fits in the cache, etc). 64 bit OS's totally compatible with 32bit applications. of course, if a process needs more than a couple gigabytes of address space, then 64bit is a no-brainer, but there's really not that many applications which need that sort of memory.
Is that generally true? I thought running in 64bit got you access to twice as many registers and that generally you'd expect better performance from x86_64 code not worse. While pointers would be doubled in size, most of your memory consumption would boil down to base types that'd be of the same size.
For some applications the performance advantage of having more registers is small and the overhead of a larger executable is larger. There is not any sort of absolute or fixed rule that says that all applications *always* run faster, etc. when compiled for 64-bit, although most do. Also there are odd-ball applications that it is not worth the effort to make them 64-bit clean. And there are *still* a few bits and pieces that have not (officially) migrated to 64-bit (Adobe's Flash is not *officially* available as a 64-bit plugin, although a 'beta' 64-bit version is available).
jh _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Robert Heller wrote:
At Wed, 13 Jul 2011 09:17:55 +0100 (BST) CentOS mailing list centos@centos.org wrote:
On Wed, 13 Jul 2011, John R Pierce wrote:
for many things, 32bit code is more compact and runs faster than 64bit code (primarily because the code is smaller, so it requires fewer fetches, more code fits in the cache, etc). 64 bit OS's totally compatible with 32bit applications. of course, if a process needs more than a couple gigabytes of address space, then 64bit is a no-brainer, but there's really not that many applications which need that sort of memory.
Is that generally true? I thought running in 64bit got you access to twice as many registers and that generally you'd expect better performance from x86_64 code not worse. While pointers would be doubled in size, most of your memory consumption would boil down to base types that'd be of the same size.
<snip> Coming in late, here, but 64 bit should run as fast or faster, since the registers are larger, and 64-bit hardware is optimized for by 64-bit compilers. In addition, you get twice as much data per fetch. The upshot is that there is no good reason for it to run slower.
mark
On Wednesday, July 13, 2011 09:00:13 AM m.roth@5-cent.us wrote:
Coming in late, here, but 64 bit should run as fast or faster, since the registers are larger, and 64-bit hardware is optimized for by 64-bit compilers. In addition, you get twice as much data per fetch. The upshot is that there is no good reason for it to run slower.
This is not true in the general 64-bit architecture case. It may be mostly true in the specific x86_64 case, but there is a reason a 32-bit userland is used on 64-bit SPARC linux, and that reason is code bloat (which makes it take longer to load from disk, it takes up more cache, etc). Version 9 SPARC64 has no performance benefit over 32-bit SPARCv9 code; the only benefit is increased memory capability per-process. But that's due to the SPARC architecture; Alpha, MIPS64, Power, IA64, and 64-bit S/390 are all different (among the more popular non-x86_64 64-bit architectures).
And while the ideas and theory of x86_64 version ia32 code can be argued as long as we want to, it really boils down to measurements and benchmarks of your actual code. If it actually runs faster compiled ia32, then run it ia32; if x86_64 is faster, then run it there. Whether somebody thinks it should run faster always in x86_64 mode is totally irrelevant if measurements prove otherwise.
And, once again, this is an upstream thing; upstream EL ships multilib-enabled x86_64 and so that's what CentOS ships.
Lamar Owen wrote:
On Wednesday, July 13, 2011 09:00:13 AM m.roth@5-cent.us wrote:
Coming in late, here, but 64 bit should run as fast or faster, since the registers are larger, and 64-bit hardware is optimized for by 64-bit compilers. In addition, you get twice as much data per fetch. The upshot is that there is no good reason for it to run slower.
This is not true in the general 64-bit architecture case. It may be mostly true in the specific x86_64 case, but there is a reason a 32-bit userland is used on 64-bit SPARC linux, and that reason is code bloat (which makes it take longer to load from disk, it takes up more cache,
<snip> True, but I was thinking of identical code, compiled differently (64 vs 32). Code bloat... ah, yes, the joys of OOPs....
mark "that's another rant"
On 7/13/2011 7:27 AM, m.roth@5-cent.us wrote:
Code bloat... ah, yes, the joys of OOPs....
What does OOP have to do with this?
Doubling the pointer size affects C, awk....
Consider Erlang, a functional language, not OOP in any way at all, not even in the sidecar way of, say, Perl. The most recent versions have a new build option that lets you build it as a 64-bit binary, except that it uses 64-bit pointers and ints only for a few "bulk data" type of things, such as ETS, its built-in memory-backed database system. For everything else, it uses 32-bit values.
The resulting virtual machine emulator behaves like you'd built it as a 32-bit executable -- 4 GB limits and all -- except when you go to access ETS or one of the few other things it accesses through 64-bit pointers. Because the amount of data it is shuffling around is half the size it would be if you built it as a pure 64-bit application, it is measurably faster on some workloads.
There's no free lunch. 64-bit is not an unqualified good.
--On Wednesday, July 13, 2011 09:00:48 AM +0200 Ljubomir Ljubojevic office@plnet.rs wrote:
RHEL/CentOS always installs both 32-bit and 64-bit libraries
I disagree. I'm not sure what the algorithm is to select all-64 vs mixed-32-64 on 64 bit platforms, but I've got a datapoint that disproves the generalization: My Thinkpad laptop had a fresh install of RHEL6 and it was (sufficiently) 64-bit pure that I had to later install lots of 32 bit libraries for some legacy applications. IIRC, that included glibc.
Devin
At Wed, 13 Jul 2011 09:56:39 -0600 CentOS mailing list centos@centos.org wrote:
--On Wednesday, July 13, 2011 09:00:48 AM +0200 Ljubomir Ljubojevic office@plnet.rs wrote:
RHEL/CentOS always installs both 32-bit and 64-bit libraries
I disagree. I'm not sure what the algorithm is to select all-64 vs mixed-32-64 on 64 bit platforms, but I've got a datapoint that disproves the generalization: My Thinkpad laptop had a fresh install of RHEL6 and it was (sufficiently) 64-bit pure that I had to later install lots of 32 bit libraries for some legacy applications. IIRC, that included glibc.
RHEL / CentOS through *5* installs both 32-bit and 64-bit libraries by default. I guess starting with RHEL / CentOS *6*, they (Red Hat) are going to 'pure' 64 bit on 64-bit machines...
Devin
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Always Learning -
B.J. McClure -
Devin Reade -
Edo -
John Hodrien -
John R Pierce -
Lamar Owen -
Les Mikesell -
Ljubomir Ljubojevic -
m.roth＠5-cent.us -
Nguyen Vu Hung (VNC) -
Robert Heller -
Roberto Alvarado -
Warren Young