# 32-bit - Do you use it?



## forquare (Jun 26, 2019)

Hi all,

I'm posting this purely out of interest.

Last week Canonical said they were dropping 32-bit support in Ubuntu 19.10 (they've since backtracked on this, for specific packages).  
Apple have announced that the end for 32-bit macOS applications is also coming in the near future.
For personal use, the last time I bought (new) x86 hardware was in 2006 when I bought my MacBook.  Since then it's all been amd64.  I've been in industry for a short 10 years, and don't think I've seen any 32-bit hardware racked up.

I'm not particularly interested in discussing Ubuntu and macOS.  I'm interested to know whether people here use 32-bit software on their FreeBSD machines - mainly I'm interested in commercial use, I know some users here use older hardware for personal use and probably still count on 32-bit releases.
I am also interested, if anyone here knows, how much additional resource it takes to support and maintain both i386 and amd64 as Tier 1 platforms?

Personally, I install 64-bit FreeBSD on the machines where it is installed.  I'm not sure if I need to.  They all have amd64 CPUs with 8GB or more RAM...
I also install lib32 at installation - which I understand effectively enables 32-bit support? - but I don't know if I actually need to install it.  Perhaps I'll not install it next time I do a fresh install…

I am not about to start campaigning for FreeBSD to drop 32-bit support!  I'm just interested to hear that people are still using 32-bit software on FreeBSD and looking to fill some gaps in my knowledge.


----------



## Junkie (Jun 26, 2019)

In my case  32bit support is used for i386-wine only
Well all the packages in the repo are built for the main arch (in your case x86_64 a.k.a AMD64). There is only one exception in ports, its emulators/i386-wineIf you're have no plans to use it or some specific binaries which impossible to recompile for AMD64, you could freely deinstall lib32 dirs. Also 32bit support should be disabled in kernel config and kernel should be rebuild if you want to  get rid of 32 bit support.


----------



## bookwormep (Jun 26, 2019)

All (3) of my computers use 32-bit architecture. Yes, they are older; and yes I use them as an independent paralegal professional. Earlier in life I learned computer programming, but I use
those skills to maintain and enhance my systems hardware (by myself).


----------



## shkhln (Jun 26, 2019)

forquare said:


> Last week Canonical said they were dropping 32-bit support in Ubuntu 19.10 (they've since backtracked on this, for specific packages)



Please note, in Debian multiarch the library installation paths are adjusted so the packages built for various architectures can be installed side by side. The 32-bit packages for x86_64 Ubuntu are actually normal i386 packages built for i386 Ubuntu release. Presumably, Canonical _just_ wanted to stop building packages for i386 Ubuntu repo, which is totally understandable considering that i386 Ubuntu installation images are also being dropped. That, however, effectively means dropping i386-on-x86_64 support, unless they do additional work on whatever building infrastructure they have, which might be quite unpleasant.

It's good to see an insane over-engineered Debian solution bite Ubuntu in the ass, but it's not particularly relevant to FreeBSD.


----------



## rigoletto@ (Jun 26, 2019)

You need the 32-bit libraries to build virtualbox for instance; however if you build using ports-mgmt/poudriere the jail will have the libs and so you don't need them in the "actual" system, I don't.


----------



## rigoletto@ (Jun 26, 2019)

forquare said:


> I am also interested, if anyone here knows, how much additional resource it takes to support and maintain both i386 and amd64 as Tier 1 platforms?



I am not involved with src and so I can't tell anything specific but that bring some overhead. One of the issues I am aware is sometimes the code changes in x86_64 but the x86 code is forgotten. This is more of an annoyance than anything else but there is some work to unify both code base to avoid this kind of problem and lower the overhead.


----------



## Jeckt (Jun 27, 2019)

I admin many boxes that are 64bit, but I have two Pentium3 laptops using 32bit I mainly use for diagnostics, etc. As time goes by I wouldn't be surprised if 32bit BSD becomes a kind of gateway introduction for people who want to tinker with old hardware, but don't have many (if any) options on Linux. Well there's Windows, but Win10 often performs pretty bad on fairly modern hardware..


----------



## rotor (Jun 27, 2019)

I used to use 32-bit on an old notebook.  But that notebook has since gone to the big docking station in the sky.

Now, all my FreeBSD usage is 64-bit.


----------



## balanga (Jun 27, 2019)

I still occassionally used some old Thinkpads which won't run 64-bit FreeBSD. I was actually surprised to find my T60 was 32-bit, but my T61 which looks pretty similar is OK with 64-bit.


----------



## ralphbsz (Jun 27, 2019)

My main server at home is 32 bit. There is no need to replace it for several years.
The laptop I use every day at home is 32 bit (it doesn't run FreeBSD though, it is a Mac).
I have a handful of laptops I use for testing and prototyping, which are nearly all 32 bit (one of them may have a 64bit CPU).


----------



## tingo (Jun 27, 2019)

It is not that simple.
Mostly I use 64-bit. But I have some older machines that are 32-bit only, but still capable of doing the job I want; these run 32-bit FreeBSD.


----------



## chrcol (Jul 14, 2019)

I am the only voter for option 4, I install lib32 out of habit but I am pretty sure the lib32 files dont actually get used for anything now on my systems.  They there as a "just in case"

Although I remember a few years back one of my fellow admin's on a irc network I co-founded, asked me how I got lib32 installed as it seems one of the bits of software we use there does/did depend on them, but thats the only thing.


----------



## nandi (Mar 6, 2022)

I am using 32 bit version on a laptop with 1GB ram. Its running with very decent speed, my kids playing on it with snes9x and dosbox staged. Only problem the segmention fault when tried to run chromium and smtube. 
The same laptop very struggling when i boot to Devuan or even Windows Xp.


----------



## kpedersen (Mar 6, 2022)

I have a couple of dedicated 32-bit laptops running around running Windows XP so I can run older "non-cloud" versions of various software.

I probably own double the number of 32-bit Intel workstation machines than I do ARM and aarch64 and I don't think I am alone so it is a bit weird seeing commercial vendors drop support for 32-bit Intel citing limited users and yet focusing heavily on ARM(64) which is even more niche.

But frankly, modern software (including open-source) is so heavy and crap, I tend to run old versions of FreeBSD (and matching era of ports collection) offline on a number of my aging machines. I don't find it particularly productive using a slow recent i.e Gimp when an older version is much more fast and snappy. Same goes for OpenOffice and Blender.

I used to think modern 64-bit processors (i3, i7, etc) had better power management and I was wasting energy with my older stuff (P4, CoreDuo, etc) but then I actually measured it and it turns out the older stuff also used far less energy.


----------



## ralphbsz (Mar 7, 2022)

My server at home is 32 bit, and will remain so for the foreseeable future (it's not a 64-bit CPU, it's an Atom).


----------



## Deleted member 30996 (Mar 7, 2022)

I use i386 FreeBSD 11.2-RELEASE-p2 on my Sony Vaio with Intel Dual-Core T2060 @1.6Hz and 2GB RAM. 

It's running right now, I've listened to music and watched youtube videos on it over the weekend.

I tried to give it away twice. First guy couldn't enter the password 11111. The second was thrown because he couldn't see the password being entered and  when he brought it back asked if I believed in evil spirits.

I missed it and won't give it away again.


----------



## grahamperrin@ (Mar 7, 2022)

Initially I was unsure about _use_. Then I changed my response:

☑ I install 64-bit FreeBSD and use lib32



rigoletto@ said:


> … need the 32-bit libraries to build virtualbox …



That example helped to jog my memory. Thanks rigoletto@


Somewhere above, I briefly saw the phrase _Calcium 64_  … a merger of the words _Pentium_ and _64_ (literally boss-eyed whilst waking up, it takes a few seconds for things to straighten) combined with calcium on my mind (loss of sleep, _ca_t on intravenous _Ca_ at emergency vets, emergency over, touch wood).


----------



## grahamperrin@ (Mar 7, 2022)

Junkie said:


> In my case 32bit support is used for i386-wine only … emulators/i386-wine …



Side note: the port was removed around four months ago. From <https://cgit.freebsd.org/ports/commit/?id=056135a38ed91f3eff4fcd9578962fbd01d3a34b> by Alexander88207: "… emulators/wine is now providing i386 support on amd64, …".

PS, I just noticed the date (2019). Sorry!


----------



## drr (Mar 7, 2022)

I have 64bit FreeBSD on my machines, but I also have 32bit libraries installed as I leave the default installation options unchanged. I do not think I have ever used the 32bit libraries though.


----------



## covacat (Mar 7, 2022)

pi zero


----------



## Profighost (Mar 7, 2022)

It's interesting: 
Something happens in the Linux world and a discussion about it starts here. 

*Ubuntu is a turnkey OS,* based on Linux.
Turnkey means the user wants to get served something ready-to-use with as less (learning) effort as possible, the fewer the better, at best none. 
Including not caring much about which Apps to use, what real alternatives there are, or how to change anything besides the look.
Short: 
Give them something colorful, foolproof and fully automated (Firefox, VLC-Player, a picture viewer, LibreOffice, facebook, netflix, amazon, porn...) and (app.) 90% of all users are happily satisfied - or at least yield into it. 

*The crucial point is: Who makes the decisions?*
In a turnkey OS the users only want to make minor, in fact meaningless decisions.
Therefor the real decisions are made by the developers of a turnkey OS, or at least the ones which assemble the distribution.
And this means, they decide and only care about the majority of their users. The more conform the better.
It's like everywhere else in mass production: 
Either you're satisfied with "one-size-fits-all" or have to look _yourself_ for complete other way.

To put it with love one may say all major Linux distributions try to make the computer's world easy for not-so-much-in-computers-interested-users on an alternative base than the commercial ones. 
For me that's okay, as long as there are further options, including the choice not use it. 
To put it a bit evil one may say all major distries misuse Linux by betraying the basic concept of the originally idea of what a good OS has to be: 
The Unix philosophy

*Unix philosophy* means you only_ add_ things on a _modular_ base. (And more, of course)
The fundamental core idea could be put this way:
The final power results from _you_, by assembling modules, tailoring individually the most efficient solution fitting best your current needs. 
Thus needs to bring effort like learning, knowing which modules there are, how to concenate, adapt and maybe modify them. (Or, in my case, at least try to learn it. ) What sometimes even means programming. That's why all unlixlike systems are by their nature also are software development environments, even perhaps by default installation neither quite complete nor perfect ones - but they are, coming at least with one shell, including scripting, a text editor and at least a compiler.

Because exactly this is the way of offering best work efficieny possible.
This costs effort by the user, but pays in long term by gaining more and more effiency in use.

Those are the two priciple ways: 
As effortless use as possibly versus best efficiency possible. 
Both ruling out each other. You cannot have both. That's a law of nature. 
But at least if there is something like FreeBSD, you can decide. Even to make FreeBSD something effortless usable - but (almost) all decision are made by you.

One can decide to go this way or that way.
But one cannot really discuss if one is right and the other wrong, because both are just different ways.
What definitively is not possible, is an argument about of obsolete or not. Because ideas cannot age.

For an OS that follows the Unix philosophy this means: 
modules stay. 
New ones are always welcome, because every additional module makes the system more powerful, flexible, adaptive, extpands its use. 
But no module is removed unless there is a very good reason to do so, or there is a replacement that offers the same service and consists of the same usage. 
Therefor age is no reason. Judging the usability of something just because of its age is moronic. You wouldn't stop using tables or the wheel just because of the ideas are thousands of years old.

Of course, we really don't need no drivers to connect electromechanical terminals writing on paper only anymore such like the Friden Flexowriter, because besides there are no such dinosaurs anymore available and if even it wouldn't make sense to print anything on paper, because we have monitors. Absolutely no sense of having support for such installed by default anymore, of course. But it wouldn't hurt either if the driver would be still available somewhere. Doesn't need to be updated, just needs a bit of storage where to stay. What would this cost? Roughly estimated 1..2kB? So what?!  

On the other hand there is many "old" hard- and software still in use, and many, many people are thankful there still is the possibility to use it. Because it works, it's good, they love it the way it is, there is no reason to replace something working, and nobody wants to be forced to change anything if there is no real need for it.

The main reason we need 64bit for is to have a bigger address room. But else the potential of 64bit are hardly needed really.  
For most of the stuff we really practically use we wouldn't actually need 64bit. Not even 32bit. 
24bit is more than enough to represent all colors a human eye can distinguish. 16bits are more than sufficient for anything a human ear can hear and a keyboard would be fully satisfied with 8, or by me even 10 bit, if one needs 800 additional buttons for whatever some needs so many buttons...)
If you are no physicist doing some wacky calculations about the universe you don't even need the precision of 32bit floating point values. Looking at what one wants from calculator results in reality mostly even 8bit are overdrawn. 

Except someone wants to sell you something new, what in most cases just turns out to be "the same in green" (as we say in german.)
When a new version of Windows appears one may worry if all your satisfactionary functioning hard- & software will still be supported or if you need to buy a new scanner, printer, keyboard.... just because it was decided not to support those drivers no more.  
This could be put in a joke: 
What's the difference between Windows and Apple?
Windows suspends support of drivers. Apple changes plugs.

We are trashing this planet with fully functioning hardware just because somebody else forces you to buy new stuff.
(If you look at pictures of electronics landfills in Africa one may say: "Hey, I had this printer, too.")

As I said at the beginning: Ubuntu is nothing else as another attempt of a (free - whatever that means) turnkey OS, Linux based.

_*Shortly summerized:*_
*Don't compare turnkey OS with modular OS by Unix philosophy.*

FreeBSD is something else.


----------



## SirDice (Mar 7, 2022)

Profighost said:


> FreeBSD is something else.


I hate to break it to you but with 13.0-RELEASE i386 (32 bit) was demoted to Tier 2.



			[FreeBSD-Announce] FreeBSD/i386 demoted to Tier 2 for FreeBSD 13.x


----------



## Vull (Mar 7, 2022)

I've used it, but I'm not presently using it. I still have a few 32 bit machines which are perfectly _usable_, but they're slower than 64 bit machines, in general, and I can't presently find anyone, including me, who wants to use them. I have three such machines with FreeBSD already installed on them. If I could find a user for one of them, and if it were practical, both for that user, and for me, I would give one of those machines, or all of them, to that user. If I acquire another such machine, or someone who knows me acquires one, I'd be happy to use it, if it were useful to do so.

As time goes by, there are fewer and fewer situations in which such machines might be useful. The pace of change in the computer tech world is quite rapid at the moment. I cannot predict the future, but shall continue to use 32 bit machines for as long as I have them, and for as long as there are 32 bit operating systems available which are practical to use on them. If the time comes when no operating system providers remain who will support 32 bit systems, I still have archive copies of older operating system installers which might still be usable in some situations.

If I remember rightly, the directory /lib32 is provided as part of the base FreeBSD install for 32 bit machines. Taking a quick glance at the 64 bit installation on partition 12 of the laptop I'm presently using, I do not see that directory, therefore, it's my surmise, assuming that my understanding of the question is correct, that lib32 is not part of a 64 bit install. I could be wrong.

That is the essence of my "32-bit story."

As for the poll options, they don't really make a whole lot of sense to me, so I shan't be voting in this poll.


----------



## astyle (Mar 7, 2022)

I install 32-bit libs 'just in case' when I do a fresh install. That way, I don't have to worry about 32-bit support.  lib32 doesn't take up that much space anyway.  But these days, even Pi boards are 64-bit. 32-bit stuff can generally be run by a 64-bit processor (but not the other way around). When 64-bit processors were just coming out, the issue back then was that there _was_ 64-bit stuff compiled, but it could not run on a then-common 32-bit processor.  This basically got me to conclude that _direction_ of the data flow matters.


----------



## SirDice (Mar 7, 2022)

astyle said:


> When 64-bit processors were just coming out, the issue back then was that there _was_ 64-bit stuff compiled, but it could not run on a then-common 32-bit processor.


Don't confuse IA-64 with Intel 64. IA-64 is a 64 bit instruction set that was used in the Itanium line of processors. IA-64 wasn't backwards compatible with IA-32. AMD64 is actually an _extension_ of the IA-32 instruction set. Because it was an _extension_ it retained the backwards compatibility with x86 32 bit (IA-32) instructions. So it was perfectly fine to run 32 bit x86 code on an AMD64 processor. Intel wasn't going anywhere with the Itanium and therefor implemented their own AMD64 instructions, it had several different names over the years but is now called Intel 64.


----------



## grahamperrin@ (Mar 8, 2022)

I'm trying to figure out how file(1) might be used to identify files that use lib32.

This: 


```
% file /usr/local/ICAClient/npica.so
/usr/local/ICAClient/npica.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
%
```

– from <https://www.freshports.org/net/citrix_ica#requiredrun> I assume that it uses Linuxulator, but does it (also) use lib32?


----------



## _martin (Mar 8, 2022)

grahamperrin see ELF.

I'd argue that Intel 64 is ambiguous term. As SirDice said IA64 is totally different to IA32 (different architecture). I personally prefer name x86_64 or amd64.
It's with sadness I look at my IA64 assembler book (Itanium architecture for programming). My first crack ever was on IA64.  >: )


----------



## kpedersen (Mar 8, 2022)

grahamperrin said:


> I'm trying to figure out how file(1) might be used to identify files that use lib32.


I believe `file` might be the wrong tool. Instead prhaps something like `lld`would show you the path and then you can grep ones that are in a 32-bit lib path.



_martin said:


> My first crack ever was on IA64.  >: )


Heh, nice. What was the program you cracked?

The only non-x86 crack I have bodged together was on SPARC with the classic Motif GUI builder BX Pro (https://motif.ics.com/products/bx-pro). Exciting stuff 

I didn't have Radare2 back then. That would possibly have made it less time consuming haha.


----------



## _martin (Mar 8, 2022)

kpedersen said:


> Heh, nice. What was the program you cracked?


xpls - it was a Swiss knife for managing HP XP and P9500 arrays. It had a check for license expiration. I didn't use radare2 or IDA (no Ghidra back then) but good old gdb on HPUX and trial-error approach. Fun and exciting, as you said.  And yeah, those tools do help a lot with static analysis.

Nice, I do have one Sparc - Sun Fire V120 on Solaris 10 but never did any pwning on it.


----------



## grahamperrin@ (Mar 8, 2022)

_martin said:


> see ELF.



Thanks, is `32-bit` (in the example above) a reliable indicator? 

I mean, does the command below come close to listing files (not necessarily executables) in /usr/local that require `lib32`?

`sh`

`find /usr/local -type f -exec bash -c '[[ $(file -b "'{}'") == *" 32-bit "* ]] ' \; -print`

It's (naturally) long-running, matches include: 

/usr/local/lib32/gcc10/libitm.so.1.0.0
/usr/local/llvm13/lib/clang/13.0.1/lib/freebsd/libclang_rt.asan-i386.so


A parallel `sh` run of the command below quickly finds things such as /usr/local/bin/mulberry:

`bfs /usr/local -type f -exec bash -c '[[ $(file -b "'{}'") == *" 32-bit "* ]] ' \; -print`


----------



## _martin (Mar 8, 2022)

That's _the indicator. Even kernel relies on it (flip that one byte and execution fails). Many tools rely on that:  file(1) does read from that header,  brandelf(1) command plays there, so does  elfctl(1). 
To see what's the elf object about you can use  readelf(1) and  objdump(1) (among others). 

You can get into weird territory with x86_64 very fast because 64b object can execute 32b code and in theory load 32b library (and vice versa). But putting hacks aside readelf/objdump is really a good way to determine the type of the ELF object.


----------



## grahamperrin@ (Mar 9, 2022)

_martin said:


> That's _the indicator. …



Thanks.


Side note



grahamperrin said:


> … (naturally) long-running, …



The *very* long run of the command (I did not exclude jails) _might_ help to make OpenZFS issue 12779 reproducible – <https://github.com/openzfs/zfs/issues/12779#issuecomment-1062613967> – I assume that `E` would normally indicate _EiB_ (exbibytes), not _error_ …


----------



## bookwormep (Mar 12, 2022)

This thread has evolved, so much so that, to change my original vote. I am now using FreeBSD on amd64 hardware. No lib32 in use either.


----------

