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

32-bit got culled in active development branch 15.0-CURRENT.
Now we know what it means getting on the downhill tier-path.

First comes Tier2 then Tier3 and then death. No more i386. So sad.

Sadly there is no communication on such decisions and it is kept silently in the dark. Nothing that can be used for PR-attention and celebrating loyalty.
It may hit you without notice and hurt your investments.

https://www.freebsd.org/platforms/

If that affects you take the 2024 Community Survey now. Last day last chance.

https://freebsdfoundation.org/blog/2024-freebsd-community-survey-is-here/

Time to look for 32-bit lifebelts elsewhere.
 
It wasn’t kept “silently in the dark“ e.g.


I’d prefer the limited developer resources are used on new or growing platforms rather than legacy platforms.

In an ideal world it would be lovely if there were unlimited resources and choices didn’t have to be made, but that’s not the real world.

But agree with the filling in the survey point.
 
It wasn’t kept “silently in the dark“ e.g.
Well, at this point is was at least not clear to me that downgrading to Tier2 is a fast downhill path to death.


I’d prefer the limited developer resources are used on new or growing platforms rather than legacy platforms.
Glad that you name it. FreeBSD is struggling with a decreasing base of developers. Fluctuation is high especially among port maintainers.

IMO it does not make much sense trying to accelerate user growth with a decreasing number of developers.

Devels are welcomed with loud fanfares but they depart in silence.
 
There’s also a paragraph in the 14.0 RELEASE notes (near the end):


And 14 is supported for 5 years so not sure I‘d call that a “fast downhill path”.

But I don’t know what tier 2 will actually look like especially in terms of ports. And given that a lot of upstream projects will also continue to neglect legacy platforms.
 
Is there anything preventing an individual from taking the last set of source supporting i386 and forking it? Keep it alive for their own needs?
 
Is there anything preventing an individual from taking the last set of source supporting i386 and forking it? Keep it alive for their own needs?
too expensive.
replacing hardware is cheaper unless you bought a several acres super computer from the 90s or early 2ks
 
Is there anything preventing an individual from taking the last set of source supporting i386 and forking it? Keep it alive for their own needs?
And don’t forget ports - it might not be “just” the OS.

Newer hardware may also be more power efficient so *may* be “greener”. But then you get into the discussion about being even greener not using resources to build new machines etc so maybe not a compelling argument.
 
What are the specific i386 machines you want to keep alive?
I only have 1 (a nice Chunky ThinkPad Z61 with a fancy titanium top). The rest run DOS, Win9x.

But coincidentally that is more than FreeBSD ARMv7 devices I own. And yet they are choosing to keep that platform alive?

I would bet that the majority of us here are more likely to have FreeBSD working on i386 kit than Armv7. Our poorer countries are probably likely to have an even higher proportion.
 
But coincidentally that is more than FreeBSD ARMv7 devices I own. And yet they are choosing to keep that platform alive?
Not for long if you read the 14.0 RELEASE notes - https://www.freebsd.org/releases/14.0R/relnotes/

FreeBSD 15.0 is not expected to include support for 32-bit platforms other than armv7. The armv6, i386, and powerpc platforms are deprecated and will be removed. 64-bit systems will still be able to run older 32-bit binaries.

We expect to support armv7 as a Tier 2 architecture in FreeBSD 15.0 and stable/15. However, we also anticipate that armv7 may be removed in FreeBSD 16.0. We will provide an update on the status of armv7 for both 15.x and 16.x at the time of 15.0 release.
 
There was a kind of "silent data corruption" detected in ZFS recently. I am sure there is a lot more of such issues when building for 32bit, and it is impossible to pinpoint them.
So, should there be a distribution that is likely unstable and potentially risky, or is it better to cease it entirely?
 
Is there anything preventing an individual from taking the last set of source supporting i386 and forking it? Keep it alive for their own needs?

No. Anytime a true open source project does something you don't like you can do a full fork. That's the beauty of it. You have the same rights as the original project.

And a form of control. If there is too much momentum behind a projected split the original maintainers might reconsider the planned change.
 
I still have a 32-bit only Intel Atom machine. It is incredibly low power. Still runs for an hour without plugged in on its original ~10 yr old battery. It has a faulty screen, so I can't give it to someone else. So I'm using it mainly as a server. I don't want to throw it away and contribute to the increasing problem of tech trash.

I honestly did not expect FreeBSD to do this. If this is final, I am not interested to invest any more time on FreeBSD as I did not get any solution to the issues I have on i386 and am fearful that I will not be able to run it even on x86_64 on older hardware in future (which is probably the case already due to MESA changes).

FreeBSD doesn't even have a MESA Amber port. Debian (by extension Devuan) has one. Arch has one too. Devuan runs very well on i386 without bloated systemd that Debian has. Devuan/Debian have challenges supporting i386 but the good thing is that they did not give up.

It seems like FreeBSD has chosen its path. I don't know if the decision will change. If it doesn't, time to say goodbye to FreeBSD then. Seriously disappointed at FreeBSD as a project.
 
I am not interested to invest any more time on FreeBSD
What kind of investment are we talking about here?
FreeBSD doesn't even have a MESA Amber port. Debian (by extension Devuan) has one. Arch has one too.
That will happen only when someone really invests their time.
It seems like FreeBSD has chosen its path.
And it wasn't a secret.
I don't know if the decision will change.
Even if it will, it will be caused not by such posts, only if someone will invest A LOT of their time.

In any case, that's targeted for 15, so you have all the time until the 14 EOL, which is estimated to be November 30, 2028.
 
FreeBSD doesn't even have a MESA Amber port. Debian (by extension Devuan) has one. Arch has one too. Devuan runs very well on i386 without bloated systemd that Debian has. Devuan/Debian have challenges supporting i386 but the good thing is that they did not give up.
A 2 seconds search for mesa amber gives me


Have you tried it ?

On another note, at the bottom of the release notes:
The project may choose to alter this approach when FreeBSD 15.0 is released by extending some level of support for one or more of the deprecated platforms in 15.0 or later. Any alterations will be driven by community feedback and committed efforts to support these platforms. Use FreeBSD 14.0-RELEASE and following releases, or the stable/14 branch, to migrate off 32-bit platforms.
Any alterations will be community feedback and committed efforts to support these platforms.
So if there is some feedback associated with people that contribute back to maintain i386, then maybe in 10 years i386 will still be supported.
 
As far as I know, discussions about removal of 32bit platforms are held at freebsd-arch mailing list starting from this post by John Baldwin.
As you can see, you can read the discussion, even if you are not subscribed to it, on mailing list archive and the last post was at Mon, 14 Aug 2023 21:38:37 UTC by Brooks Davis. From April to August, 2023.
I'm not subscribed, but read on archive from time to time to track whether any plans about architectural changes which I could be bitten exists or not.
 
It is disappointing that 32bit will eventually no longer be supported. FreeBSD is still my favorite 32bit OS. I have an Aspire One KAV60 and it's runs so well with FreeBSD 14.0 Release. Will be a shame when I have to move over to another system on my 32bit systems. :D
 
That will happen only when someone really invests their time.
It is not only i386 btw. MESA changes also should affect x86_64 arch. I think there should be a solution to such a common issue. If an operating system can't even support commonly used arches, then it is broken.

If it can't support older graphics cards on any arches, FreeBSD Handbook should say something like older graphics cards don't work (which is a way to admit that FreeBSD isn't well-suited for older hardware). As you can see in the linked thread I followed the steps in Handbook, but it showed me a "Caught signal 6 (Abort trap)" error instead. It doesn't even mention to try installing x11-drivers/xf86-video-intel which I had to figure out by myself. How is this ok for a project like this?

A 2 seconds search for mesa amber gives me
Thanks. But building from source has issues. Things go wrong, weird messages pop-up, needs manual intervention, needs experience in the build tools etc. Not ideal for everyone. And how would I uninstall the installed files if things didn't work out? It can get messy.

A port would be better to have so that the installation process is easier. I got an old version of mesa (not MESA Amber) working which is attached here.

Any alterations will be community feedback and committed efforts to support these platforms.
So if there is some feedback associated with people that contribute back to maintain i386, then maybe in 10 years i386 will still be supported.
This sounds positive but I don't know if it actually is. The deprecation has already started. It shows on startup, it shows when I want to build graphics/drm-515-kmod on i386 and so on. No message is reassuring that it might not be deprecated. Why would I want to spend time in this project if I know I won't be able to use it in future?
 
How is this ok for a project like this?
Sorry for spelling out obvious things, but everything is maintained by community, there is no large commercial entity behind FreeBSD (well, there is sponsored work, but it only covers that much), and if some instructions for setting things up are better in some linux distro, it's only because someone volunteered to do that; you can easily send updates for FreeBSD handbook (and that's what I would call real "time investment").
 
How is this ok for a project like this?

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 (there's threads on here that help with cheap well-supported 64-bit hardware, saved from e-waste) or c) complain to the provider of the operating system that came with that laptop that you paid a licence for that they no longer support. See how far that gets you.
 
No message is reassuring that it might not be deprecated. Why would I want to spend time in this project if I know I won't be able to use it in future?
FreeBSD is BASICALLY developed by the community of volunteers. Earned developers are very, very limited, unlike huge, huge and huge Microsoft.
And even soooooo huge Microsoft drops support for "old" hardwares, which are quite new for us, FreeBSD community. For example, Pre-ZEN AMD CPUs are dropped from Windows11.
And if you want something, i386 for this case, kept supported, developers who has enough skill in the area but not having the SPECIFIC hardware cannot even test/investigate the problem without supports from whom having the hardware, unfortunately.
And this forum is basically helps WITHIN USERS each other. If you want i386 supported even after 15, you would need popping into appropreate mailing lists, filing problem reports on bugzilla to attract developers' eyes.
 
For your info:
Documents for how we can contribute.

List of public keys who has @freebsd.org email addresses.
Not all of them are src committers. These includes ports committers, docs committers, secretaries and so on. And not all of them are active just now with reasons of each. You can see how limited project's resources are.
I've filed several bug reports which are not yet (even) confirmed. Some of them has patches proposed by me and others, but I cannot say "Hurry up!" to them.
 
Back
Top