32-bit - Do you use it?

What's your 32-bit story?


  • Total voters
    61
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.
 
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.
 
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).
 

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.
 
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.
 
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..
 
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.
 
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.
 
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).
 
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.
 
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.
 
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.
 
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.
 
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.
 
Initially I was unsure about use. Then I changed my response:

☑ I install 64-bit FreeBSD and use lib32

… 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, cat on intravenous Ca at emergency vets, emergency over, touch wood).
 
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.
 
It's interesting:
Something happens in the Linux world and a discussion about it starts here. :what:

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. :cool:
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.
 
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.
 
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.
 
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.
 
Back
Top