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

And some are not updated and have security vulnerabilities:

Bash:
# pkg_admin -K /usr/pkg/pkgdb fetch-pkg-vulnerabilities
# pkg_admin audit
Package perl-5.38.2 has a symlink-attack vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2011-4116
Package perl-5.38.2 has a sensitive-information-disclosure vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2023-31484
Package perl-5.38.2 has a sensitive-information-disclosure vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2023-31486
Package libxml2-2.10.4nb6 has a use-after-free vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2023-45322
Package gnutls-3.8.2 has a timing-side-channel vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2023-0553
Package pcre-8.45 has reached end-of-life (eol), see http://cdn.NetBSD.org/pub/NetBSD/packages/vulns/eol-packages
Package libssh2-1.11.0nb2 has a integer-overflow vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2019-17498
Package gnupg2-2.4.3nb2 has a out-of-bounds-write vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2022-3219
Package wget-1.21.4nb2 has a sensitive-information-disclosure vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2021-31879
That isn't fair.
FreeBSD VuXML Documenting security issues in FreeBSD and the FreeBSD Ports Collection

 
"cy@, post: 641586, member:
The backward compatibility problem is a much larger issue. Remember how badly 64 bit inodes went? This would be worse. Much worse."

Does not ring a bell. The more bits the less I care.
PD: I have the answer. Install Windows in all the desktops you have.
 
Last edited:
My feelings are 32bit should still be supported as a 1.5 tier. Not every feature needs to be supported. For example ZFS which really needs a larger memory address space. Ports should compile for it unless it requires a 64 bit address such as maybe a database and port maintainers still need to support compiling for 32 bit.

I'm not sure how this will affect the 32bit compatibility layer but I suspect that will also be dropped. That is an issue for me because I want the ability to run old 32bit Windows programs with Wine. Most programs don't need 64 bits and so were never compiled for it. Of the 64 bit versions of windows programs that exist many include installers that are 32 bit.

If you need to ditch the 32 bit kernel then do so; but maintain the compatibility layer. And don't lock the 32 bit ABI at 14.
 
FYI:
Intel already announcing X86S architecture, which drops many old (legacy) functionalities.
If Intel actually switches to it completely and X86-compat vendors, including AMD, follow the route, native 32bit OS'es cannot even boot on it.
If this happens, working 32bit PCs would dissappear on the market even as second-handed, as users who need to run 32bit native OS'es for some reason would rush to purchase them to keep their business.
And even worse, developers having 32bit PCs would be strongly asked for selling theirs for, i.e., avoid stopping some facilities at factories, meaning much harder to develop/test i386 arch.

I'm now much, much more pessimistic about the future of i386 arch than before.
 
I haven't had any I386 based machines for several years however, I'm said to see FreeBSD is dropping the support fro the 32bit architectures . It's a sign of how fast the technology surrounding computers and their related hardware ecosystems progresses. I'm still going to keep running FreeBSD as my daily driver OS on my workstation as it's a royal pain in the but to get it tweaked to where I can comfortably use it.
 
I have a client who uses a property management application expressly designed for Windows XP.
The app absolutely will not run on anything except true XP.
The vendor wants $20,000 to sell him the "upgrade" to the current version, so he continues with Windows XP.

I am certain there are other critical apps in a similar situation.
Those trapped with these apps are well advised to mothball a few system boards that can boot their required OS.
 
I have a client who uses a property management application expressly designed for Windows XP.
The app absolutely will not run on anything except true XP.
The vendor wants $20,000 to sell him the "upgrade" to the current version, so he continues with Windows XP.

I am certain there are other critical apps in a similar situation.
Those trapped with these apps are well advised to mothball a few system boards that can boot their required OS.
That is a "pay me now or pay me 10x later when it's a disaster"
 
That is a "pay me now or pay me 10x later when it's a disaster"
If it can work offline in a VM, I don't think there is too much risk of disaster waiting to happen.

I still run ye'old classic Microsoft Money '97 in a modified DOSBox. Quite happy with it.
 
If it can work offline in a VM, I don't think there is too much risk of disaster waiting to happen.

I still run ye'old classic Microsoft Money '97 in a modified DOSBox. Quite happy with it.
I agree with the VM solution; that was my first thought. That gave way to licensing and keys and "Can you create a VM image from an existing physical XP system?".
 
I agree with the VM solution; that was my first thought. That gave way to licensing and keys and "Can you create a VM image from an existing physical XP system?".
It is a tricky subject but (in the UK at least) cracking software for the purposes of interoperability is legal, so long as you own a license (a receipt of the software purchase is enough).

In short, a fresh install with an activation crack is my recommendation for old (and new...) software. Keeps the install much cleaner and more deterministic.
 
MBR images are easily done with GHOST then that image installed on a VM disk of the same size.

I keep GHOST images of all my windows VMs.
 
The vendor wants $20,000 to sell him the "upgrade" to the current version, so he continues with Windows XP.
That vendor is performing blackmail. I'm not sure I would want to work with software from a vendor with such bad ethics. Anecdote below.

It is a tricky subject but (in the UK at least) cracking software for the purposes of interoperability is legal, so long as you own a license (a receipt of the software purchase is enough).
It might be legal to do so, but then you run smack into the next problem: Support. Say you crack a new version, and then need help from the vendor: they may deny you because you are not paying for support of the version you are running. They may also decide to give you support. I used to work in a company that sold a rather powerful yet complex system, and we had a large support department for it. I think about 1/3 of all our support work was for users who did not actually have a legal license, or were not paying for support. In many cases, we helped them anyway, because doing so is a good business decision.

Now the anecdote: In the early 1990s, I purchased a pretty expensive piece of software, about $30K, and installed it on my desktop machine, which was a NeXT (the Steve Jobs 68K based graphical disaster). Used it quite a bit. A few years later, I got a phone call from their support department: They would like me to move to a different hardware/OS platform, because I was the last user of this software on the NeXT. That morning, there had been 2 users (the other was an analyst at the CIA), but they had convinced the other one to move. So I said: "But I like it, and it works well ... you need to sweeten the deal somehow". So they offered to upgrade me for free from 1 workstation to 2, and to throw in a few years of free support. Since my office mate had an IBM RS/6000 that had oodles of CPU power, I took the deal, and got a free upgrade. And they were able to drop support for a quite unusual platform.
 
It might be legal to do so, but then you run smack into the next problem: Support. Say you crack a new version, and then need help from the vendor: they may deny you because you are not paying for support of the version you are running.
Then I would show them the receipt of purchase.

Plus, for consumer software, support is overrated in 2024, as in, we don't really get any ;)

They would like me to move to a different hardware/OS platform, because I was the last user of this software on the NeXT.
Heh, thats quite cool. Thouh it also would have been fun to turn it into a social experiment and seen what they would have done if you remained with the original purchased software.
 
I have seen three heinous cases of vendor blackmail.

The first is a scheduling program for medical professionals.
The upgrade cost was five digits... cuz it is for "doctors".

This required a database conversion, which was a ghastly failure.
I called their support, spoke with an honest tech.
The original source code was lost after the company was sold and bought a few times.
He said all they can do is "damage control" (his words).
The "upgrade" was unusable, so they went back to their old version and will limp along until they retire.

The property management software was the same.
The clients are at the end of their working years.
Their business is 100% dependent on this app handling all their numerous property duties.
The app and its (wonderful) 3rd party DB manager can be installed on any machine that runs WinXP SP3.

The third is a classified package, source code is also lost.
 
, , , a few years of free support. Since my office mate had an IBM RS/6000 that had oodles of CPU power, I took the deal, and got a free upgrade. And they were able to drop support for a quite unusual platform.
What is the % of original parts for the IBM? I have heard that model is from 1980s.
 
Back
Top