Moving 32 bits to Tier 2

Following others, FreeBSD is turning i386 into a second class citizen, https://lists.freebsd.org/pipermail/freebsd-announce/2021-January/002006.html

rvp

pin I would shed a tear--except that all 3 of my 32-bit x86 boxes are dead: 386 box - untouched for 20+ years; AMD K6 box - CPU dead; AMD Athlon box - MB dead -- capacitors failed.

JuvenalUrbino

pin They did the same to sparc64 on 12.x, then decided to eventually drop SPARC support in the upcoming 13-RELEASE

nia

Specifically, we expect that time_t will remain 32 bits on i386.

Best time to double its size would have been 10+ years ago

nia True, keeping time_t as such is non-sense.

musl has shift to 64 sometime ago

musl 1.2 is now available and changes time_t for 32-bit archs to a 64-bit type.

So has Alpine.
It irritates me that Void hasn't done it yet. I run x86_64 but, it bothers me because

SECURITY ADVISORY: All releases through 1.2.1 are affected by CVE-2020-28928 and should be patched or upgraded to 1.2.2.

*Above quotes from, https://musl.libc.org/

nia

I guess the problem with the 2038 hard limit is that there's genuinely a lot of very good 32-bit x86 hardware that will stay working into the far future. I know people that swear by Panasonic Toughbooks and use them daily, and that hardware isn't going to die any time soon - same with industrial PCs, PC Engines, and Soekris boards. I'm against electronic waste, if it works and is efficient it should stay working.

The way NetBSD chose to do 64-bit time_t is probably weird. OpenBSD later did it by breaking ABI, but NetBSD did it by versioning system calls. The old 32-bit time_t system calls still exist and will be used if you run a binary that was built before the switch, on the whole making the switch painless.

nia OpenBSD later did it by breaking ABI, but NetBSD did it by versioning system calls.

Void is a rolling release and binary packaging on Linux should be much simpler to handle. The problem is that xbps can't handle reinstalling all the packages without a version bump, which would require all packages in the repository to be re-built.

I know it sounds strange, as this what we do all the time on bulk-builds but, this is not the way Linux people are used to do things. Even though, Void was created by a ex-NetBSD person and, probably because of this the package manager doesn't know how to handle the situation.

boomer3200

The tier 2 transition captures a tendency to flee forward by removing standard features as an exercise in progress (modernization and refocusing by cutting code) without providing alternatives on FreeBSD. These issues led me to switch to NetBSD as my daily driver years ago, but really struck a chord in this case.

Generally you hear the reasonable suggestion that release engineering and security updates take resources, so efforts will focus on new hardware and i386 can be maintained by any interested contributors on an independent release schedule. Except that there are no dedicated port maintainers, automated testing, and publicly discussed goals for tier 2 on FreeBSD unlike NetBSD. Try finding any standard instructions, places to ask questions, or build routines for ports on PowerPC or Sparc64 on FreeBSD.

Then you hear the alternative that, of course, one always has emulation (bhyve or binary compatibility) for older releases.

In fact, 32 bit binary compatibility on FreeBSD for roughly any pre-9 release on i386 and amd64 has been broken in the sense of failing completely with basic distribution binaries for over a decade. That's a real shame that killed my interest in jails and will likely never change when i386 goes away (around release 15 I suppose). Bug reports on the compat issues were dismissed as non-critical and closed without testing the partial changes towards resolutions. Again, completely unlike the open discussion and willingness to review issues until resolution or full removal of the related systems with NetBSD.

I really appreciate that NetBSD maintains excellent backwards compatibility going back to the first releases. I test and build with older releases/toolchains on fast recent hardware all the time. I personally always thought ABI backwards compatibility was a major value add of the BSD centralized development model. And yet we cannot run old binaries and we keep losing traditional tools in base (telnet, ftp, etc.) on FreeBSD.

And then we have emulation. Bhyve has no ability to emulate any ide/isa devices or the types of PCI scsi controllers and network cards needed to run old releases. You can't passthrough newer devices either. Qemu would be an alternative, but is not accelerated unlike with nvmm/haxm on NetBSD. Your only option on FreeBSD is VirtualBox at this point.

FreeBSD is still a good server or desktop system with a large set of packages for routine work, but I don't understand their roadmap anymore. On 4-8 it was clearly adding core subsystems to take advantage of modern hardware without breaking legacy compatibility on servers and desktops. Now it really seems to be chasing power saving and newer video drivers for laptops, with some extra lockdown, profiling, and tunable sysctls for the enterprise server crowd.