🚀 go-pugleaf

On 01/04/2024 07:55 AM, Dan Purgert wrote:
> On 2024-01-04, Richard Owlett wrote:
>> My machine is 64 bit capable [Dell Latitude E6410]
>> I'm running Debian 9.13 [reported by /etc/debian_version].
>>
>> In the past I have had both 32 and 64 bit versions available.
>> How do I determine which is currently running?
>
> uname -r
>
> (or uname -a if you want to see "everything")
>
>

Thank you for quick response.
It reports "4.9.0-13-686-pae".
I understand "686" indicated 32-bit.
What does "4.9.0-13" tell me?

On 2024-01-04, Richard Owlett wrote:
> My machine is 64 bit capable [Dell Latitude E6410]
> I'm running Debian 9.13 [reported by /etc/debian_version].
>
> In the past I have had both 32 and 64 bit versions available.
> How do I determine which is currently running?

uname -r

(or uname -a if you want to see "everything")


--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860

On 04/01/2024 14:20, Richard Owlett wrote:
> On 01/04/2024 07:55 AM, Dan Purgert wrote:
>> On 2024-01-04, Richard Owlett wrote:
>>> My machine is 64 bit capable [Dell Latitude E6410]
>>> I'm running Debian 9.13 [reported by /etc/debian_version].
>>>
>>> In the past I have had both 32 and 64 bit versions available.
>>> How do I determine which is currently running?
>>
>> uname -r
>>
>> (or uname -a if you want to see "everything")
>>
>>
>
> Thank you for quick response.
> It reports "4.9.0-13-686-pae".
> I understand "686" indicated 32-bit.
> What does "4.9.0-13" tell me?
>

It says you're running debian version 13 of the 4.9.0 kernel. The 686 as
you say indicates 32-bit and the -pae means your kernel was compiled
with physical (page) address extensions.
See: https://en.wikipedia.org/wiki/Physical_Address_Extension


--
Chris Elvidge, England
I WILL NOT DRIVE THE PRINCIPAL'S CAR

On 2024-01-04, Richard Owlett wrote:
> On 01/04/2024 07:55 AM, Dan Purgert wrote:
>> On 2024-01-04, Richard Owlett wrote:
>>> My machine is 64 bit capable [Dell Latitude E6410]
>>> I'm running Debian 9.13 [reported by /etc/debian_version].
>>>
>>> In the past I have had both 32 and 64 bit versions available.
>>> How do I determine which is currently running?
>>
>> uname -r
>>
>> (or uname -a if you want to see "everything")
>>
>>
>
> Thank you for quick response.
> It reports "4.9.0-13-686-pae".
> I understand "686" indicated 32-bit.
> What does "4.9.0-13" tell me?
>

Kernel version 4.9.0 (patch 13)


--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860

On 1/4/24 05:45, Richard Owlett wrote:
> My machine is 64 bit capable [Dell Latitude E6410]
> I'm running Debian 9.13 [reported by /etc/debian_version].
>
> In the past I have had both 32 and 64 bit versions available.
> How do I determine which is currently running?
> TIA
>

Just FTR, if it's a systemd sever (and Deb 9 should be)
this command has what you'd need and quite a bit more relevant information:

hostnamectl

(Architecture: x86-64)

Richard Owlett wrote:
> My machine is 64 bit capable [Dell Latitude E6410]
> I'm running Debian 9.13 [reported by /etc/debian_version].
>
> In the past I have had both 32 and 64 bit versions available.
> How do I determine which is currently running?
> TIA
>
Type 'uname -m' and your terminal will print out either 'x86_64' ==>
64-bit kernel or 'i686' ==> 32-bit kernel.

https://stackoverflow.com/questions/246007/how-to-determine-whether-a-given-linux-is-32-bit-or-64-bit

nyyssit

On 2024-01-08, nyyssit@posteo.net <nyyssit@posteo.net> wrote:
> Richard Owlett wrote:
>> My machine is 64 bit capable [Dell Latitude E6410]
>> I'm running Debian 9.13 [reported by /etc/debian_version].
>>
>> In the past I have had both 32 and 64 bit versions available.
>> How do I determine which is currently running?
>> TIA
>>
> Type 'uname -m' and your terminal will print out either 'x86_64' ==>
> 64-bit kernel or 'i686' ==> 32-bit kernel.
>
> https://stackoverflow.com/questions/246007/how-to-determine-whether-a-given-linux-is-32-bit-or-64-bit

I would like to say this answer is somewhat misleading because it only discusses
the kernel, but then the question also wasn't very precise.

There are really two questions:

1) Is the kernel 32-bit or 64-bit?

2) Is the userland (applications) 32-bit or 64-bit?

On both x86 and ARM, you can have:

A) A 64-bit kernel with a 64-bit userland

B) A 64-bit kernel with a 32-bit userland

C) A 32-bit kernel with a 32-bit userland

D) A 64-bit kernel with both 64-bit and 32-bit userland

Because both x86 and ARM 64-bit processors also natively understand 32-bit
instructions, this is quite possible.

You can use "file /bin/bash" as a rough estimation for what kind of userland you
have.  For instance:

/bin/bash: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]6b11360e339f231f17484da2c87d0d78554e31, for GNU/Linux 3.2.0, stripped

So now you might ask: why would I have a 64-bit kernel with a 32-bit userland?

There are several reasons for this.

One is that you need to run 32-bit binaries.  This came up quite a bit in the
early days of x86_64.  Modern Debian, for instance, has "multiarch" support and
is quite capable of having 32-bit libraries installed alongside 64-bit ones.
Such a system can run binaries from both.

This 32/64 situation is routine on the Raspberry Pi.  Starting with the model 3,
they are all 64-bit capable but kept a 32-bit userland until just recently.
That maintained compatibility across boards.  On Debian, you'd run a 64-bit
kernel for those 32-bit binaries.  In fact, I recently discussed this on my blog
at
https://changelog.complete.org/archives/10622-live-migrating-from-raspberry-pi-os-bullseye-to-debian-bookworm

The 64-bit kernel is capable of accessing the full 64-bit address space, but the
32-bit processes remain limited on how much memory they individually can access.
Still, collectively across the entire system, the processes can use more than
4GB of RAM without weird tricks.

Incidentally, with qemu binfmt support, it is, in fact, possible on Debian to
transparently run binaries for entirely unrelated architectures on a single
system through emulation.

- John

On 01/17/2024 03:40 PM, John Goerzen wrote:

Welcome and thank you for contributing.

> On 2024-01-08, nyyssit@posteo.net <nyyssit@posteo.net> wrote:
>> Richard Owlett wrote:
>>> My machine is 64 bit capable [Dell Latitude E6410]
>>> I'm running Debian 9.13 [reported by /etc/debian_version].
>>>
>>> In the past I have had both 32 and 64 bit versions available.
>>> How do I determine which is currently running?
>>> TIA
>>>
>> Type 'uname -m' and your terminal will print out either 'x86_64' ==>
>> 64-bit kernel or 'i686' ==> 32-bit kernel.
>>
>> https://stackoverflow.com/questions/246007/how-to-determine-whether-a-given-linux-is-32-bit-or-64-bit
>
> I would like to say this answer is somewhat misleading because it only discusses
> the kernel, but then the question also wasn't very precise.

I [the OP] disagree. *GRIN*
The answer wasn't misleading. It precisely answered my exact question.
The universe of discourse was Debian 9.13 on a 64 bit capable machine.
  [ that machine having had a 32 or a 64 bit OS at various times].

There were two possible motivations for asking the question:
    1. are additional applications restricted to 32 bit?
    2. OS is outdated, would a 32 or 64 bit upgrade be more comfortable?
       [ N.B. I said "comfortable", not "recommended" ;/

I chuckled when reading your post as I spent ~5 decades in combination
of engineering &/or end-user support [primarily analog not digital].

Thank you for a trip memory lane (CK722's and type 80's anyone).


> to Debian[
> There are really two questions:
>
> 1) Is the kernel 32-bit or 64-bit?
>
> 2) Is the userland (applications) 32-bit or 64-bit?
>
> On both x86 and ARM, you can have:
>
> A) A 64-bit kernel with a 64-bit userland
>
> B) A 64-bit kernel with a 32-bit userland
>
> C) A 32-bit kernel with a 32-bit userland
>
> D) A 64-bit kernel with both 64-bit and 32-bit userland
>
> Because both x86 and ARM 64-bit processors also natively understand 32-bit
> instructions, this is quite possible.
>
> You can use "file /bin/bash" as a rough estimation for what kind of userland you
> have.  For instance:
>
> /bin/bash: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]6b11360e339f231f17484da2c87d0d78554e31, for GNU/Linux 3.2.0, stripped
>
> So now you might ask: why would I have a 64-bit kernel with a 32-bit userland?
>
> There are several reasons for this.
>
> One is that you need to run 32-bit binaries.  This came up quite a bit in the
> early days of x86_64.  Modern Debian, for instance, has "multiarch" support and
> is quite capable of having 32-bit libraries installed alongside 64-bit ones.
> Such a system can run binaries from both.
>
> This 32/64 situation is routine on the Raspberry Pi.  Starting with the model 3,
> they are all 64-bit capable but kept a 32-bit userland until just recently.
> That maintained compatibility across boards.  On Debian, you'd run a 64-bit
> kernel for those 32-bit binaries.  In fact, I recently discussed this on my blog
> at
> https://changelog.complete.org/archives/10622-live-migrating-from-raspberry-pi-os-bullseye-to-debian-bookworm
>
> The 64-bit kernel is capable of accessing the full 64-bit address space, but the
> 32-bit processes remain limited on how much memory they individually can access.
> Still, collectively across the entire system, the processes can use more than
> 4GB of RAM without weird tricks.
>
> Incidentally, with qemu binfmt support, it is, in fact, possible on Debian to
> transparently run binaries for entirely unrelated architectures on a single
> system through emulation.
>
> - John
>

On 01/18/2024 08:39 AM, John Goerzen wrote:
> On 2024-01-18, Richard Owlett <rowlett@access.net> wrote:
>> On 01/17/2024 03:40 PM, John Goerzen wrote:
>>
>> Welcome and thank you for contributing.
>>
>> I [the OP] disagree. *GRIN*
>> The answer wasn't misleading. It precisely answered my exact question.
>
> My apologies; that was a poor choice of words on my part.

Not to worry. It was partially the phrasing that got me chuckling.
It reminded me of a customer visit I made when an engineering tech.
The customer had sent corporate a thank you for sending a helpful
engineer. Our previous rep was a degreed engineer. I never graduated,
but I had "heard" the question the customer was attempting to ask.

>
> And thanks for making me look up CK722.  I can't claim to be old enough to
> remember those, but I most definitely enjoy stories about older tech.  I'm just
> old enough to remember UUCP and BBSs.

I have to admit the CK722's were my father's. My PET and KIM were too
modern for the context ;/

I quoted the body of your discussion as it is something youngsters
should be aware of.


>
> - John
>

On 2024-01-18, Richard Owlett <rowlett@access.net> wrote:
> On 01/17/2024 03:40 PM, John Goerzen wrote:
>
> Welcome and thank you for contributing.
>
> I [the OP] disagree. *GRIN*
> The answer wasn't misleading. It precisely answered my exact question.

My apologies; that was a poor choice of words on my part.

And thanks for making me look up CK722.  I can't claim to be old enough to
remember those, but I most definitely enjoy stories about older tech.  I'm just
old enough to remember UUCP and BBSs.

- John