LinuxQuestions.org - stupid q: how to determine version 64-bit or 32-bit?

- Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)

- - stupid q: how to determine version 64-bit or 32-bit? (https://www.linuxquestions.org/questions/linux-software-2/stupid-q-how-to-determine-version-64-bit-or-32-bit-164741/)

Quote:

Originally Posted by noknow (Post 850833)

Running Redhat 9 (Shrike)

I can't tell if I'm running 64-bit or 32-bit. I was not the installer.

uname -a shows:

Linux <hostname> 2.4.20-20.9smp #1 SMP Mon Aug 18 11:32:15 EDT 2003 i686 i686 i386 GNU/Linux

cat /etc/redhat-release shows:
Red Hat Linux release 9 (Shrike)

cat /proc/version shows:
Linux version 2.4.20-20.9smp (bhcompile@stripples.devel.redhat.com) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 SMP Mon Aug 18 11:32:15 EDT 2003

you can run 32 bit on 64bit cos im running 32 bit mepis 8.0 on my 64 bit system so uname will only tell you the arcitecture of the os not the prosessor youre best bet is to try a 64bit live cd if it works youre 64 if not youre 32

Code:

cat /proc/cpuinfo | grep lm

If you get output, your processor support 64-bit.

Quote:

Originally Posted by vincebs (Post 850840)

I've always thought that the OS uses the same number of bits as the processor, so if you're using a 64-bit processor then your OS is 64-bit,

False. You can run a 32 bit x86 OS on a 64 bit (x86_64) CPU.

Quote:

if you're using a 32-bit processor (like most of us)

I think that is also false. I think x86_64 CPUs are in more common use for desktop PCs than the older 32 bit CPUs, even for people who are running 32 bit OS's.

Quote:

then your OS is 32-bit. Isn't it?

But in fact, the OP's OS is 32 bit.

Quote:

Originally Posted by noknow (Post 850870)

it only says "i686"

All this made me want to assume that it is 32-bit...but it is not a definite answer, unless you know what you know, you know?

You've probably realized by now that "i686" is a definite answer and does mean the OS is 32 bit. But I can't argue with your "unless you know" comment.

"i686" would not appear to be a definite answer to 32 bit vs. 64 bit unless you know.

So we know your OS is 32 bit. If you want to know whether your cpu could run a 64 bit OS see AlucardZero's answer.

NB the thread is five years old.

Quote:

Originally Posted by AlucardZero (Post 3607553)

NB the thread is five years old.

Oops. I didn't notice.

You will get exact info
#getconf LONG_BIT

Quote:

Originally Posted by AlucardZero (Post 3607553)

NB the thread is five years old.

Now even that comment is over three years old.

The resurrection of this thread made me notice the NB in the above comment. During the intervening years, there was an occasion on which another manager code reviewed work of an engineer in my group. That engineer had put "N.B." in front of warning comments in a several places where the behavior of the code would likely be misunderstood if one did not pay careful attention to the comment.

The other manager was highly critical of that use of "N.B." saying he had no idea what it meant and most people would have no idea what it meant, and we should keep "local idiom" out of our comments.

Prior to that, I would never have thought any educated English speaking person would fail to understand that use of "N.B.". My opinion of the engineer who wrote those comments remains very high. Not so, my opinion of that other manager.

Any English speaking engineers or managers here care to give an opinion? (Now that the original topic of the thread has long since been beaten to death).

This post was meaning less once i read whole thread so i just finished with valuable answer. if you really not care about old topics then you should have removed post or post with complete with answer.

Quote:

Originally Posted by amberlinux (Post 4782240)

This post was meaning less once i read whole thread so i just finished with valuable answer.

Actually #getconf LONG_BIT is a terribly unreliable way of finding out whether the running kernel is 32 bit vs. 64 bit.

Google it and you will see many instances, such as the following, of people asking why it gave the wrong answer:

https://access.redhat.com/knowledge/solutions/26084

On a quick google search, I didn't find any good answers (as opposed to a lot of people asking the question), and I don't think anyone wants a better answer in this thread than the ones posted years ago (so I'm not going to try to put together a good explanation myself).

(I didn't use a valid Redhat license when I accessed the above link, so I only got to see the question, not the answer. If you have a Redhat license you might see the answer there).

... and after about 8 years here is a solution to this thread:

this will tell you what version your kernel is running

Code:

[schneidz@hyper ~]$ uname -a -m -p

Linux hyper 2.6.43.8-1.fc15.x86_64 #1 SMP Mon Jun 4 20:33:44 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

this will tell you what byte length your cpu is capable of:

Code:

[schneidz@hyper ~]$ cat /proc/cpuinfo

processor        : 0

vendor_id        : GenuineIntel

cpu family        : 6

model                : 28

model name        : Intel(R) Atom(TM) CPU  230  @ 1.60GHz

stepping        : 2

microcode        : 0x212

cpu MHz                : 1599.996

cache size        : 512 KB

physical id        : 0

siblings        : 2

core id                : 0

cpu cores        : 1

apicid                : 0

initial apicid        : 0

fpu                : yes

fpu_exception        : yes

cpuid level        : 10

wp                : yes

flags                : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm dts

bogomips        : 3199.97

clflush size        : 64

cache_alignment        : 64

address sizes        : 32 bits physical, 48 bits virtual

power management:



processor        : 1

vendor_id        : GenuineIntel

cpu family        : 6

model                : 28

model name        : Intel(R) Atom(TM) CPU  230  @ 1.60GHz

stepping        : 2

microcode        : 0x212

cpu MHz                : 1599.996

cache size        : 512 KB

physical id        : 0

siblings        : 2

core id                : 0

cpu cores        : 1

apicid                : 1

initial apicid        : 1

fpu                : yes

fpu_exception        : yes

cpuid level        : 10

wp                : yes

flags                : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm dts

bogomips        : 3199.97

clflush size        : 64

cache_alignment        : 64

address sizes        : 32 bits physical, 48 bits virtual

power management:

lm means long-mode addressing (i.e.- 64-bit).

extra credit:
physical id will count how many physical cpu's the system has.
core id will count how many cores each cpu has.
because of intel hyperthreading, it makes the os believe there are 2 cpu's even though there is only 1 (the example above both cpu's have the same physical id).
http://en.wikipedia.org/wiki/Hyperthreading

I use NB a fair amt; concur with johnsfine. :)

^ so what does it mean.

i heard of nbd (no big deal) ?

NB - Nota Bene - Take note
http://en.wikipedia.org/wiki/Nota_bene

Quote:

Originally Posted by schneidz (Post 4784085)

^ so what does it mean.

i heard of nbd (no big deal) ?

The original person complaining wasn't quite young enough for that effect (expecting any abbreviation to be a common phrase in English, used in texting).

But I'm old enough (or eschew texting enough) that prior to your reminder I forgot that the existence of so many new abbreviations makes it harder to recognize the Latin abbreviations that have been standard English for over two hundred of years.

I had look into one url other day which had good info how to find OS bit information.

http://www.expertslogin.com/linux-ad...t-information/

I hope all followers of this thread helps even its quite old.