Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi all,
I need help determining which processor architectures I own so I can download the appropriate Linux distributions for each of them. I'm fairly sure I have all 64-bit processors (I think), but I'm not sure which architecture they are (i686, x86 or something else). The first pc has an Intel Celeron 420 1.60 GHz, the second one is an AMD Athlon II Dual-Core M300 2.00 GHz, and the last one is an Intel Pentium Dual core E2180 at 2.00 GHz.
I'm fairly sure I have all 64-bit processors (I think), but I'm not sure which architecture they are (i686, x86 or something else).
All the 64 bit processors in the Intel/AMD x86 family support the same two different architectures (each processor supports both these architectures):
They all support a 64 bit architecture, which has various names: x86-64, AMD64, EM64T. When downloading software, it doesn't matter which of those is named, they all refer to the same architecture.
They all support a superset of the various 32 bit x86 architectures, such as i686. When downloading software, you might want to select software compiled for the more advanced 32 bit architecture (i686 vs. i486). But any 32 bit architecture software works with any x86-64 CPU. The choice of which 32 bit software you use should not be influenced by which 64 bit CPU you use it on.
For extremes of squeezing the last spec of performance in a CPU specific manner, you might consider the L2 cache size for each CPU (you can look those up online). With a relatively low L2 cache size, many applications run fastest if you have installed a 32bit application on a 64bit OS (below 2GB physical ram, they might be a bit faster on a 32 bit OS). With higher L2 cache size, a lot of that performance difference goes away and those applications run just as fast pure 64 bit. Many other applications simply run faster in 64 bit regardless of all those hardware details, so first you need to distinguish those before you start micro managing the details by L2 cache size. I only included that L2 cache info because you seem intent on distinguishing between your CPU chips for optimum software choices.
If you do want to try installing 32 bit applications in 64 bit Linux (for performance comparison and/or general use), that is possible in both Debian based distributions such as Ubuntu and in Red Hat based distributions such as Centos or Fedora. But it is significantly easier in Red Hat based distributions than in Debian based. The 32 bit apps will run just as well once properly installed in Debian based, but the effort to get them properly installed may be much greater.
When choosing between a 32 bit and 64 bit OS, be aware that a 64 bit OS can run both 32 bit and 64 bit programs, while a 32 bit OS cannot run 64 bit programs. Also be aware, there is a moderate amount of extra overhead in both physical ram and hard disk space to running a 64 bit OS vs. 32 bit. If you have decent size ram and disk that extra overhead is too trivial to worry about. With small ram or small disk that overhead might be a big enough fraction of the total to affect your decision. With 2GB or more of ram, I wouldn't worry about the ram aspect of that (even with less than 2GB, I might still select 64 bit). I don't know a similar number for disk size (there are too many other factors) but I wouldn't buy a disk under 500GB anyway and whatever the 32/64 don't care point is for disk size, I'm sure it is FAR below 500GB.
All of those are processors which use the IA32 instruction set (also known as x86) and can use 64 bit extensions (EM64T for Intel, AMD64 for AMD, also known as x86-64 and, rarely, x64).
How is the OP going to run uname or lshw on his machine if it's not currently running Linux?
(There is always a danger that the OP could download a live CD for just this purpose...not necessarily a ridiculous suggestion, if the OP is in a 'distro hopping' phase)
...and its worse than that, in that the 'unames' give you the wrong answer: they answer the question 'What version of the Linux kernel am I running?, or 'For what arch is the kernel in the software that I am running compiled?', when the OP wants to know about the capabilities of the hardware, and not the software that is currently running. So, really, they give a correct answer to the wrong question, but that can still be enough to deceive.
So, for 64 bit x86 hardware (the commonest case, for any recent machine), the hardware is also capable of running 32 bit software, so the 'uname' answer could point towards 32 bit, when the element of the answer that is desired is that this hardware can run 64 bit software (and 32 bit, obviously).
The same isn't true in reverse for older hardware, that was 32 bit only, but it sounds as if the OP doesn't have that.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.