Slackware - InstallationThis forum is for the discussion of installation issues with Slackware.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
+ can compile and run 64-bit binaries
+ can utilize more than 4 GB of memory per process.
+ offers slightly better performance in certain types of computations
- can not run 32 binaries - may be a problem since there still are programs that are 32-bit only.
- 64-bit binaries are larger than 32-bit
+ allows you to compile and run both 32 and 64 bit binaries.
- takes up more hard drive space
- is more difficult to maintain since you need to have both 32-bit and 64-bit versions of almost everything.
- sometimes requires additional hassle when compiling software to make it link the right libraries.
If you have a netbook, check carefully. Some Intel Atom CPUs do not support 64-bit. If you need any third-party drivers that are not included with Linux then check to make sure there are 64-bit versions of the drivers available.
You will get a lot of different opinions about 32-bit versus 64-bit. I'd say, use 64-bit unless you have a reason not to use it. If you've already got a 32-bit system installed, then there isn't a big reason to install 64-bit. The next time that you do an install or upgrade you can consider switching to 64-bit. A 64-bit system may use a little bit more memory and disk space, though it also may be slightly faster.
The main benefit of 32-bit is compatibility. A 32-bit system will run on both 32-bit and 64-bit CPUs. Most kernel software and drivers have a 32-bit version. The size of RAM is not an issue, since 32-bit Linux can address up to 64 GB (with Physical Address Extension enabled in the kernel). Your system only has 2 GB so you don't even need to enable PAE.
A 64-bit system may be a little faster for running 64-bit applications. The ability to run 64-bit applications is the main reason why you will eventually want a 64-bit system. If you want to run 32-bit applications on a 64-bit system then you need to install the "multilib" files. Ordinary 32-bit applications will run as long as you provide the required 32-bit libraries needed by the applications. The 32-bit applications might not run any faster on a 64-bit system.
The only reason that I've found to not use 64-bit is on a 32-bit CPU, or when I've needed special kernel or driver software that only supports 32-bit. An example of that is "dmraid". Proprietary drivers from some hardware manufacturers may also only be available for a 32-bit kernel. You may still be able to build your own 64-bit versions of some of those programs but it may be simpler to use use a 32-bit version of Linux.
If you have a mixture of computers with 32-bit and 64-bit CPUs then you may want to run a 32-bit Linux system on all of them so that you can keep the software very similar. If you use your Linux system to create 32-bit boot discs or build 32-bit applications then a 32-bit system may be more convenient. However you can usually do all of those same things on a 64-bit system with the correct scripts and software configuration.
There were really two main reasons for the creation of 64-bit CPUs. First, AMD created a moderately priced 64-bit CPU to market to consumers and compete with Intel 32-bit consumer CPUs. As a marketing strategy, Intel had kept 64-bit limited to expensive premium CPUs in the server and corporate market. AMD's decision forced Intel to start marketing 64-bit to consumers. Intel had to develop their own less expensive consumer 64-bit CPUs and that gave AMD a head start getting into the market. Once the genie was out of the bottle, Intel and Microsoft could no longer tell consumers that they didn't need a 64-bit CPU. I think that Microsoft got caught somewhat by surprise, and had to quickly release a 64-bit version of XP to keep consumers happy. Without this marketing push, 64-bit may have been adopted much more slowly.
The second reason is because Microsoft never fully implemented Physical Address Extension (PAE) support in 32-bit versions of Windows. Even the 32-bit server versions of Windows had a kind of kludged way of supporting PAE. Because they don't fully support PAE, 32-bit versions of Windows are limited to 4GB of RAM. Intel had kept consumer based chip-sets limited to 4 GB of RAM (or less). However, other chip-set manufacturers did not make that distinction between consumer and server chip-sets and started to support more than 4 GB of memory. Microsoft decided to make customers buy 64-bit versions of Windows rather than giving them support for PAE in 32-bit versions (when they released Vista). Vista changed the driver model in Windows and was a perfect opportunity for Microsoft to fully support PAE in 32-bit versions (they chose not to). That might have been different if 64-bit CPUs didn't become popular, but we'll never know. Memory capacity on motherboards was certainly growing to the point that consumers were likely to complain about the lack of support for over 4 GB. Again it was marketing of more and more memory capacity on motherboards that drove a need for a change in Windows.
32-bit versions of Linux fully support PAE, and can address up to 64 GB of RAM. Ironically (due to hardware marketing) most motherboards that support over 4 GB of RAM have 64-bit CPUs. PAE is mostly useful when running 32-bit Linux on a 64-bit CPU. Consumer versions of Linux mostly support 64-bit because it is there, not because there was any great need for 64-bit. There are some server applications that greatly benefit from 64-bit support. Without the outside forces of AMD and motherboard manufacturers moving consumer PCs to 64-bit, there would probably be fewer consumer 64-bit Linux distributions and applications. For my own single-user workstation use I have found very little difference in performance between 32-bit and 64-bit Linux on the same hardware. Since 64-bit CPUs are optimized to run in 64-bit mode, it is fair to assume that there may be some benefit to running 64-bit software on a 64-bit CPU. That benefit is more likely to occur with applications re-designed to take advantage of a 64-bit CPU. As the focus shifts away from 32-bit operating systems, the performance differences will probably increase with newer CPUs. Eventually it will be 64-bit versions of software that are better supported and more available than 32-bit versions. One thing that most people agree on is 64-bit CPUs were eventually going to be needed, even if they weren't needed by most people when they were marketed. Because Linux has no profit motive driving the upgrade process we are each free to decide when it is time to use 64-bit.