[SOLVED] slackware current on netbook - x86 or x64 version to choose?
SlackwareThis Forum is for the discussion of Slackware Linux.
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.
slackware current on netbook - x86 or x64 version to choose?
Hello folks!
Finally, windows 7 on my brothers acer emachines n450 netbook (eMachines 350 10.1 inch Netbook ) with 2 Gb RAM stop to working - something with directories service.
his agree to replace win with linux on that machine.
he use it in car, mostly as mediaplayer -movies, audiobooks, music...
CPU is intel atom n450 - 64 bit instructions, two threads.
2 Gb RAM - max size.
HDD - dont remember, 160 gb?
Question is -it is better to install there a x86 version of slack current, or
x64?
as i remember, from one side - x64 must work bit faster, but consume more RAM...
plan to use XFCE window manager.
also i be happy to any advices there too
PS when new slack is come? nearly two years since 14.1...:-O
Last edited by WiseDraco; 09-27-2015 at 03:47 AM.
Reason: update specs
Either really. The memory footprint of x86 is smaller, but you won't be utilizing the full capabilities of your hardware resources.
Is 2GB the full max the system supports? If you could expand the RAM, do so. Usually some Netbooks with 64-bit support configurations of 1GB, 2GB, and 4GB.
If you can't expand it, then 2GB is okay. I've ran 64-bit Slackware with 2GB RAM with a 4GB swap space without too many hiccups.
Considering that x64 usually come with huge needs of LOL (Linux On Linux), aka multilib, for almost all trivial tasks, I strongly recommend you to use i586 until your system memory is beyond 64GB RAM.
So, in few words, my suggestion is: if your system memory is beyond 64G RAM, go x64, if not, go x86. Keep it simple, go KISS.
I've ran 64-bit Slackware with 2GB RAM with a 4GB swap space without too many hiccups.
Congratulations! So you managed to get a 2GB RAM system which behave something like a Slackware (i586) with 1GB system memory! Be proud and continue to waste your system resources!
Last edited by Darth Vader; 09-27-2015 at 06:11 AM.
normally for 2gigs of ram id say 32bit
but the cpu is weak and would perform better on 64bit, so idk (more registers let the compiler get away with things)
Considering that x64 usually come with huge needs of LOL (Linux On Linux), aka multilib, for almost all trivial tasks, I strongly recommend you to use i586 until your system memory is beyond 64GB RAM.
So, in few words, my suggestion is: if your system memory is beyond 64G RAM, go x64, if not, go x86. Keep it simple, go KISS.
64G RAM seems a bit high for a 32bit system, considering the max allowable RAM for 32bit is 4G.
Considering that x64 usually come with huge needs of LOL (Linux On Linux), aka multilib, for almost all trivial tasks,
Really? Would you mind to list those trivial tasks that can't be done without multilib? Besides gaming (which isn't really fun on such hardware) and Skype (which doesn't need a fully multilib system, but only few selected libraries) I can't think of anything trivial that needs multilib.
Considering that x64 usually come with huge needs of LOL (Linux On Linux), aka multilib, for almost all trivial tasks, I strongly recommend you to use i586 until your system memory is beyond 64GB RAM.
So, in few words, my suggestion is: if your system memory is beyond 64G RAM, go x64, if not, go x86. Keep it simple, go KISS.
I agree that any task which requires a 32 bit library to run is a trivial one.
Multilib is irrelevant for most systems with GNU/Linux. Only a handful of applications I know of still exist in a 32-bit only state and most of that is centered around gaming applications and a few older applications that have been already supplicanted by others not requiring multilib. For most systems, multilib is a waste. Unless you need multilib, ignore it.
LoL? Are you freaking kidding me using a Microsoft terminology with GNU/Linux? Linux is a kernel, not the operating system. The OS is GNU. There is no Linux on Linux like Windows on Windows. GNU/Linux uses Multilib as the terminology.
And Darth, 64-bit capable hardware has resource limits only 64-bit software can access to run more efficiently, not just effectively. 32-bit on 64-bit has been clocked at 1.7x faster, and yes it has a smaller memory footprint, mostly due to the fact you have 32-bit addressing in 64-bit address spaces, but 64-bit hardware resources can not be accessed in full by 32-bit software. In truth, I actually had full access to all my system resources and hardware capabilities, not just half of them. And 2GB of 64-bit RAM is 2GB of RAM, not 1GB. Do your math.
And as far as RAM goes, you can use 64GB of RAM, but unless you have a Xeon or Opteron server system to utilize that level of hardware it's pointless. Yes 32-bit has a standard limit of 4GB, but there is a way to extend the addressing range out using Physical Address Extensions (PAE), but all the software must be built to a CPU architecture type that supports PAE. So in essence, 64-bit with even 2GB of RAM is more efficient than 32-bit with 4GB on the same system.
My personal preference is to always go with the cpu. If the cpu has 64bit instructions, i install the 64bit version.
There was an old post where Linus described how the vm works in the kernel and the bottom line was that in order for the kernel to be able to do its mappings efficiently, the virtual memory needs to be larger that the physical. I don't quite remember it, but in 32bit mode, the kernel would have something like 1GB in its disposal and even less because of pci mappings and stuff. The only sane option for 2GB and even 1GB ram is 64bit. This is of course from a low level inner workings Linus's point of view and not something that can be noticed by the user.
From a practical point of view, you will not observe any speed difference in daily stuff between 32/64 bit and the memory footprint will be a little higher for 64bit. On a desktop/server processor which is a bit stronger than this atom, speed differences do exist but again not in desktop and daily stuff but mainly in multimedia / encryption programs. For example when i first migrated to 64bit, i ran ffmpeg on a video file with exactly the same options and the 64bit version was much quicker.
2GB is a bit low but i would still install the 64bit version.
My personal preference is to always go with the cpu. If the cpu has 64bit instructions, i install the 64bit version.
There was an old post where Linus described how the vm works in the kernel and the bottom line was that in order for the kernel to be able to do its mappings efficiently, the virtual memory needs to be larger that the physical. I don't quite remember it, but in 32bit mode, the kernel would have something like 1GB in its disposal and even less because of pci mappings and stuff. The only sane option for 2GB and even 1GB ram is 64bit. This is of course from a low level inner workings Linus's point of view and not something that can be noticed by the user.
From a practical point of view, you will not observe any speed difference in daily stuff between 32/64 bit and the memory footprint will be a little higher for 64bit. On a desktop/server processor which is a bit stronger than this atom, speed differences do exist but again not in desktop and daily stuff but mainly in multimedia / encryption programs. For example when i first migrated to 64bit, i ran ffmpeg on a video file with exactly the same options and the 64bit version was much quicker.
2GB is a bit low but i would still install the 64bit version.
Using OS to Hardware is basic textbook knowledge. Any good tech worth their salt knows to match architecture and software, even if the hardware installed looks underrated. I've seen 64-bit systems with 512MB RAM working. They didn't do much, but they did boot and got to a console login and ran an httpd daemon. The only time you should use 32-bit is through the multilib/compat32 packages, and use only what you need, otherwise just write it off.
My Compaq V6503NR runs Slackware64 14.1 with a 1.6GHz dual-core Turion64 X2 and 2GB RAM and it runs it just fine. Your system is probably a bit better than mine too.
Using OS to Hardware is basic textbook knowledge. Any good tech worth their salt knows to match architecture and software, even if the hardware installed looks underrated. I've seen 64-bit systems with 512MB RAM working. They didn't do much, but they did boot and got to a console login and ran an httpd daemon. The only time you should use 32-bit is through the multilib/compat32 packages, and use only what you need, otherwise just write it off.
My Compaq V6503NR runs Slackware64 14.1 with a 1.6GHz dual-core Turion64 X2 and 2GB RAM and it runs it just fine. Your system is probably a bit better than mine too.
In the mean time for True Slackware (i586) is enough to run a KDE desktop and do some web-browsing, if you don't hit websites who asks for 1GB memory allocation for a stupid images gallery.
Like I said, go further with wasting your system resources and be happy! I for one, I need my computers to work at full power...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.