HEADS UP: FreeBSD is stopping all 32-bit Hardware support except ARMv7

Honest question since I haven't tried to research:
How many new 32bit CPUs are being designed and sold now?
 
Possibly.
If there comes brand-new 32bit CPUs in mass production, which FreeBSD already has a fair amount of working codes on it, it could be a motivation to keep 32bit archs. But this would not be come true unless any of hardware vendors which intends to bundle FreeBSD-based OS on it and conribute their codes to upstream, FreeBSD project with BSD-compatible license.
 
eternal_noob said:
Does it matter?
Click to expand...
My opinion, yes it does.
Lots of commercial OSes have or are dropping 32 bit support, primarily for support reasons. If one has ever done OS level work, it can become a major pain to support different architectures. You have machine dependent layer, everything else is in theory machine independent but they affect each other. Take filesystems like ZFS for example. You want data structures 64 bit, so that hit performance on 32 bit machines. Memory management is another area.

If the market for 32 bit cpus is shrinking/nonexistent, then dropping the support at some point is reasonable because of limited resources to maintain the code.
If the market is growing, then not dropping the support is reasonable.
If people running 32bit FreeBSD are doing so on 10 year old cpus, they can keep the hardware alive but at what cost? BIOS limitations on disk sizes, supply of parts: scrounging from other 10 year old systems may buy you time but in the end the hardware still fails.
My opinions only, agree, disagree, no problem.
 
I have two old 32-bit machines that run FreeBSD perfectly. Believe it or not, they are still very useful - one of them is used as a second computer on a daily basis. I developed libraries on them, and still do. Granted, they are slower than my daily-driver FreeBSD desktop machine, but they still have years of service ahead with the proper operating system. I'm sure there are many people here who know what I'm talking about.
I will keep using FreeBSD on those 32-bit machines as long as I can, because that's the best tried-and-true solution. However at some point in the future I will have to look for something else - and I'm not happy about that.

That being said, I understand why i386 won't be supported in 15.0. I knew it would happen sooner or later, I was just hoping developers could keep i386 alive for at least one more major release cycle. But I cannot complain.
 
We have to realize that 32-bit takes extra effort when writing code. The gotchas are discovered when when building universe. Then the developer must drop what their doing and revisit how the patch is written. Or, more commonly, the code is committed broken for 32-bit. This is why (in addition to the multitude of Linux distros having done so already) I suggested we drop 32-bit. It's a PITA in a 64-bit world.

Now, if people would step up to the plate to help fix 32-bit, but nobody has done so. We have a limited number of developers and a limited amount of developer time. I certainly don't have the time to drop more important work to fix the various 32-bit bugs and compile issues out there.

And take a look at ports. My i386 poudriere has been failing for a long time. This is because upstream software has dropped 32-bit. Do we create and maintain a bunch of patches to build 32-bit ports when upstream no longer supports 32-bit? If people feel strongly enough about it, roll up your sleeves and help out. But griping and complaining will only alienate people. Again, patches please.
 
taiwan740 said:
I think you have a choice. Either a) support the entire i386 architecture for your broken screen laptop yourself (probably the work of a thousand volunteers full-time), b) buy a used 64-bit machine
Click to expand...

It seems like even if I use x86_64 version on a 64-bit supported ThinkPad x201i, my problem won't be solved. So either way FreeBSD is broken for me on both i386 and x86_64 on older hardware. If deprecating i386 is the right thing to do, as many say around here, why not deprecate older x86_64 hardware too, instead of fixing the issues?
 
Matlib said:
Is there a clean way (= install & reboot) to change the architecture to amd64? This document suggests that there isn't :|
Click to expand...
I've never tired, but if they system is running root on ZFS, it may be possible to boot install media and install 64bit into a new boot environment.
But if one is running i386 I'd guess they are running UFS, which "I don't think there is a clean and easy way to migrate"
 
cracauer@ said:
What are the specific i386 machines you want to keep alive?
Click to expand...
Some are 586-class CPU. These have no CMOV (conditional move) instruction.
So my problem is how to crossbuild a Kernel for 586 and if possible a newer buildworld?
Would setting the appropriate compiler options do the job or is the problem more complex?
 
I am incredibly sad that FBSD doesn't run on the 6502 or 8088 processors either.
😁

There comes a time when it is necessary to throw away perfectly good hardware simply because the world has moved on.
My original IBM PC with 8088 and 5-1/4" floppies is a prime example.
The machine runs just fine... on DOS 6.2
 
Kai Burghardt said:
Why’s that? Could you elaborate? In a high-level programming language I use built‑in data types like pointer or integer and then I don’t have to care about how many bits each comprises.​
Click to expand...
Some developers do weird things. One is specifically using an integer to hold a pointer value and passing that around to later be casted back and dereferenced. Obviously for larger 64-bit pointer sizes, that gets truncated causing problems.

Making a program "64-bit safe" is basically removing this bad code.
 
Kai Burghardt said:
Why’s that? Could you elaborate? In a high-level programming language I use built‑in data types like pointer or integer and then I don’t have to care about how many bits each comprises.​
Click to expand...

One issue is that you have to be careful to not run out of virtual memory.
 
Kai Burghardt said:
Why’s that? Could you elaborate? In a high-level programming language I use built‑in data types like pointer or integer and then I don’t have to care about how many bits each comprises.​
Click to expand...
In some cases in low-level programming for kernels and alike, very complex and tricky code is mandated. Even when it becomes easier by addition of new instruction(s) on newer CPUs, the complexity is needed while supports for the specific processors are kept. For example, f00f bug of old pentium.
Remenber. EVEN HUGE ENTERPRIZE LIKE MICROSOFT DROPS SUPPORT FOR QUITE A NEW PROCESSOR LIKE PRE-ZEN AMD amd64 CPUs.
 
Kai Burghardt said:
Why’s that? Could you elaborate? In a high-level programming language I use built‑in data types like pointer or integer and then I don’t have to care about how many bits each comprises.​
Click to expand...
Yeah, but as soon as you talk to hardware, these have distinct registers, and those do very much care about where the bits from your pointers and integers do actually appear.

Also, I gave up on 32bit because ZFS developed occasional strange behaviours - not about performance, but corner-case things that shouldn't happen. Not so surprizing when one considers that the thing was written in 64bit and likely not extensively tested under tough conditions in 32bit.
So, while I am also very much against dumping old hardware (hardware can indeed live 50 years and longer without necessarily degrading), I am also glad that something like ZFS does exist at all, and wouldn't like to go back to the old ways.
 
cracauer@ said:
What? My x201 works fine last I tried.
Click to expand...
I have the "i" variety - ThinkPad x201i with "Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz"

Did you try the 64-bit? I tried the 32-bit version. I was thinking about trying 64-bit but so far what I got from this forum is discouraging and not helpful. I was thinking if I should stop using FreeBSD.

I got a response that made me think pre-Haswell is not well-supported and got no hope for that machine and should replace it. But I tried Void Linux 32-bit on that machine and it works fine (details below).

smithi said:
If there's a Linux variety that works for you, why not use it?
Click to expand...
I just tried Void Linux (there is a i686 XFCE Live ISO on their download page to easily try on any machine). I booted it up and surprise! It works like it should. Plays videos and resizing the player window doesn't slow video down. And they are doing it with mesa 23.x. No old version, no amber branch.

So, why can't FreeBSD do it? People tell me to replace the machine, when it is perfectly capable.

It seems like the limitation is on FreeBSD's side.
 
T-Aoki said:
Maybe any of onboard electrolytic capacitors would blow before running 50 years.
Click to expand...
Even the best made hardware will likely start to have issues before 30 years. Consumer grade stuff is lucky to last between 15-20 years if in constant service. Also ROHS soldered components are more susceptible to the tiny whiskers that grow and eventually short things out.
 
zspider said:
Even the best made hardware will likely start to have issues before 30 years. Consumer grade stuff is lucky to last between 15-20 years if in constant service. Also ROHS soldered components are more susceptible to the tiny whiskers that grow and eventually short things out.
Click to expand...
That is a very complicated matter. People know that the electronics they throw away do pile up in Africa and pollute the land.
But we need to get to your money, and we get to your money only when you buy new things. So you need to believe that you have to throw away the old things and buy new things.

Anyway, the stuff that I built fourty years ago does still work, some of my disks run 24/7 since 23 years, and the pentium-2 mainboard did run fine when I last started it.
 
zspider said:
Even the best made hardware will likely start to have issues before 30 years. Consumer grade stuff is lucky to last between 15-20 years if in constant service. Also ROHS soldered components are more susceptible to the tiny whiskers that grow and eventually short things out.
Click to expand...
The Computer History Museum in Mountain View is operating an IBM 1401, which was built in 1961. That makes it 63 years old. It runs every Wednesday and Saturday. The oldest functioning disk drive is in the same museum, the 1957 RAMAC; that's nearly 70 years old. To be honest, it's not fully functioning: While the data on disk can be read, they do not allow new data to be written. I think the electronics on this drive has been replaced with modern emulation. Supposedly there is another disk drive the same age in a different museum, which has the original electronics, but it doesn't function fully. I think the RAMAC is also run for demonstration once or twice a week.

I (with a little sadness) agree with the decision for FreeBSD to drop support for the i386. I can imagine that it takes quite a bit of extra work to support, the project is short on humans, and it's not worth it. Even if it forced me to re-install my OS a few weeks ago.
 
ralphbsz said:
I can imagine that it takes quite a bit of extra work to support, the project is short on humans, and it's not worth it. Even if it forced me to re-install my OS a few weeks ago.
Click to expand...

Whilst the pragmatist in me doesn't disagree, It is strange that one goal is to get more contributors by making FreeBSD "user friendly" (in a nonsense way).
But at the same dropping hardware support which may have attracted more contributors

Arguably the sort of humans that run ancient hardware, are more likely to be technical or passionate enough about the technical details to be more valuable in terms of contributions compared to i.e a bunch of Steam DRM Platform gamers wanting fancy and gimmicky desktop environments.

It is likely not feasible but if I could redirect all "false user-friendly" resources towards maintaining a cutting edge 32-bit intel support, I possibly would consider it.
 
You must log in or register to reply here.
Back
Top