Is a pure 64 bit system possible?

I was wondering if a pure 64 bit install could be done (Tumbleweed or Leap), by that I mean no 32 bit stuff at all. Is that possible, or even a good idea? Can anyone comment on the ramifications of running a “64 bit only” openSuse?

First thing that comes to mind: Wine. It pulls in a lot of the x84_64 versions of 32bit compatible libs.

If you do a default install, you will get very little 64-bit.

If you use BIOS booting, then “grub2” uses 32-bit code (and probably some older 16-bit code), because that’s what the BIOS interface requires. If you are using UEFI booting, then that’s likely all 64-bit code.

I use an old program that I compiled in 2006. And it does not work on a fresh install until I add some 32-bit libraries.

If you only use 64bit applications, then the only “-32bit” that you will probably need is “glibc-32bit”.
It is simple to strip the others out, but some updates (recently Samba) may try to re-install them unless you specify “no-recommends”

Hi
On Tumbleweed I see;


zypper se *32bit | wc -l
1912 (subtract 6 for headers) so 1906...

zypper se -i *32bit
Loading repository data...
Reading installed packages...
No matching items found.

zypper se -i *32bit|wc -l

shows 93 on my tumbleweed (all of which came from recommends when installing other stuff)
so, I just did this:

zypper remove *32bit

and it proposes to remove all 93 PLUS nvidia-computeG05 and x11-video-nvidiaG05
both of which are 64 bit and definitely needed
I could tag those as protected but then that spirals down into a rat hole with the next update

Hi
I have the nvidia drivers, but installed the hard way…

I get rid of all the lang files as well as plymouth and lock…


rpm -qa *lang --qf "%{name}
" | xargs zypper rm -u
zypper rm libply* plymouth*
zypper al *-lang libply* plymouth*
mkinitrd

You can’t get rid of 16/32 bit grub until bios/uefi changes, or the cpu stops resetting to 16-bit real mode.

You could zap all your 32-bit packages probably.

Your x86_64 kernel will still contain support for 32-bit apps. Can that even be disabled? I’m not sure. Even if disabled, the CPU support is still there, and there is no way to disable it at the hardware level currently. Particularly, some system level controls bounce through 16-bit real mode, amusingly.

So the short answer is no, it’s not technically possible to be in 64 bit long mode 100% of the time, from power-on to power-off. But, you can have a 100% 64-bit userland, which is probably what you’re actually interested in.

The boot mode is irrelevant. I am more interested in a an up and running 64 bit system and avoiding all the 32 bit stuff that gets installed whether one wants it or not.
Right now, a quick check with

rpm -qa *32bit*

shows 90, 32 bit packages installed taking up who knows how many gigabytes of disk space.
If I do

zypper remove *32bit*
zypper al *32bit*

is it going to hose my system?

In my system there are 2864 packages installed using some 11 GB.

So what do you want to recover (for what) and how much work do you want to invest in it?

Here are the sizes:

henk@boven:~> rpm -qa --qf '%{NAME}	%{SIZE}
' '*32bit*' 
libz1-32bit     95632
libdcerpc-binding0-32bit        153004
libidn2-0-32bit 116292
libnetapi0-32bit        529772
libnss_nis2-32bit       54868
libtalloc2-32bit        87684
libavahi-common3-32bit  55248
libnsl2-32bit   108556
libpopt0-32bit  51252
libargon2-1-32bit       38336
libavahi-client3-32bit  75716
libsmbconf0-32bit       616696
libjansson4-32bit       54968
libverto1-32bit 17860
libffi7-32bit   30316
libndr-nbt0-32bit       107944
libp11-kit0-32bit       389136
libndr-krb5pac0-32bit   62892
samba-client-32bit      5488
libpcre1-32bit  587288
glibc-locale-base-32bit 6482573
libdbus-1-3-32bit       380260
libgcrypt20-32bit       910240
libtevent0-32bit        79768
libsamdb0-32bit 108276
libcups2-32bit  699956
libgnutls30-32bit       1975932
python-talloc-32bit     24208
libtdb1-32bit   100148
libcap2-32bit   18056
libsamba-errors0-32bit  980392
libtasn1-6-32bit        79524
libsamba-credentials0-32bit     87420
libsamba-passdb0-32bit  349744
samba-winbind-32bit     64224
libunistring2-32bit     1579504
libnettle6-32bit        247816
libfam0-gamin-32bit     34420
systemd-32bit   354804
libdevmapper1_03-32bit  413116
libsamba-util0-32bit    509456
libdcerpc0-32bit        239012
libjson-c3-32bit        63284
libaudit1-32bit 111972
libudev1-32bit  157188
libhogweed4-32bit       231756
krb5-32bit      1996916
pam-32bit       661120
libcryptsetup12-32bit   407656
libpython2_7-1_0-32bit  2315644
libopenssl1_1-32bit     3037164
libndr-standard0-32bit  3966380
libtirpc3-32bit 252332
libkeyutils1-32bit      13836
libndr0-32bit   103844
libacl1-32bit   34504
libsamba-hostconfig0-32bit      166184
libgpg-error0-32bit     141256
libsystemd0-32bit       707156
libldap-2_4-2-32bit     424016
libselinux1-32bit       174324
libblkid1-32bit 378772
libsmbldap2-32bit       46448
libcrack2-32bit 34380
libseccomp2-32bit       153112
glibc-32bit     4484636
libsasl2-3-32bit        125224
libattr1-32bit  17972
libuuid1-32bit  30136
libtevent-util0-32bit   17784
samba-libs-32bit        15194248
libldb1-32bit   403112
libnscd1-32bit  5516
liblzma5-32bit  255376
libwbclient0-32bit      62836
libopenssl1_0_0-32bit   2756916
libcom_err2-32bit       40156
liblz4-1-32bit  87604
libgmp10-32bit  580432
nss-mdns-32bit  69318
henk@boven:~> 

For you to add them up.

And this what size they say it is:

The RPMTAG_SIZE tag holds the size of all the regular files in the payload

When people talk about a 32bit or a 64bit system,
They always talk about the applications running in a fully running system,
I don’t think anyone would be concerned with what happens when the system is bootstrapped running in real mode.

It should be pointed out that regarding the CPU, the x64 instructionset is an extension of the 32bit x86 instructionset, not a standalone and separate instructionset.
So, any thought about somehow excising 32bit support from the CPU is a non-starter.

That leaves libraries and apps that might run in 32bit.
In today’s x64 world, some apps continue to be written in 32bit because that’s all they really need to run… there is no need and could even be wasteful to use 64bit spaces when 32bits is perfectly adequate.
The only reason why we won’t have similar discussions about 8bit and 16bit is that those aren’t supported by the available instructionset so would require emulation to run those apps and <that> would be considered inefficient and wasteful.

So,
I guess I’d have to ask what the purpose or objective might be to run “only” 64bit.
If your objective is to minimize installation of unnecessary 32bit libraries, LEAP (and 64bit TW) both do that in their default installations.
If you think there would be some kind gain in system efficiency, that’s not likely.
If you think your system would use less resources, that’s not likely.

TSU

56 MiB (just used one-liner perl real quick) not worth OP’s efforts, imho.

And even then, as tsu2 explains, there can always be a program, not having need for any 32-bit libraries, that uses 32-bits instructions, either for part of it or as a whole. As long as the CPU supports it, you can not switch that off in the CPU.