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.

jmcunx

nia

And this is one of the reasons I started using NetBSD. When I heard NetBSD "fixed" 2038 on 32 bit, it went right on the only system I had at the time (32bit).

At the time I was dealing with lots of date "math" so that allowed me not to worry about the "future".

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.

boomer3200

A recent reddit thread asking why people would move from FreeBSD to NetBSD encouraged me to try to capture the reasons for a newcomer. Thought I would share here.

FreeBSD and OpenBSD are opinionated about how you should setup your system and constantly update.

You can see that as an ease of use tradeoff, but if you're hoping to do something interesting as you progress in your development, like passthrough a device to a vm or freeze a package you'll have a bad time. The base documentation on standard use cases is great, but the internals and the corners feel like they have more rough edges than NetBSD.

Most people on current laptops are probably fine with that until they run into a snafu and reinstall or ignore the inconvenience.

For Open you can wave your hand and say security, but the Free side hurts a bit more with the way they recently also dumped old + 1 release packages and architectures (386).

I started on FreeBSD almost 15 years ago and it really changed in the last 5-7. At this point I'd rather run NetBSD on multiarch and live with package build times on a cleanly architectured system I can explore.

remiliascarlet

FreeBSD tries too hard to follow Linux sometimes.
In a way I can understand the murder of 32-bits by most OS's, considering that almost everyone is on 64-bits anyway, but both NetBSD and OpenBSD don't seem to kill 32-bits anytime soon.
NetBSD because of course, it's supposed to run on everything and anything.
And OpenBSD because Theo de Raadt still finds it important to continue supporting 32-bits if my memory serves well.

doug213

remiliascarlet
Oh, you mean the same Theo De Raadt who said that the OpenBSD project has more important things to focus on than i386?
Sheep follows the sheep,
Sturgeon's law is in full effect here. I think its only a matter of time before all BSD's kill of i386.
Which is a bummer, all my machines are i386.

kc9udx

doug213 all BSDs? Well, I don't disagree. But it could be a very, very long time for NetBSD. I mean, Amiga and VAX support are still improving.

remiliascarlet

doug213 Sheep follows the sheep,

"Oh, I resorted to name calling like a child, look how based I am on the internet now!"

bsduck

Keep in mind that supporting less popular architectures has never been a main goal of the FreeBSD project. While NetBSD strives for portability and broad hardware support, FreeBSD aims to provide the best performance and support on common hardware.

Therefore it's not surprising, and not a bad thing in my opinion, to drop support for 32-bit x86. Most of such hardware is very old (20+ years), most developers don't have such machines anymore to test their code on. It also takes resources on the FreeBSD infrastructure to build and host packages for it, which can be better used for something else.

People still using such machines can use NetBSD, that's why different projects exist after all 🙂

nettester

My thinclient collection will be sad when 32bit goes away. Not that most of them do anything but some are (and likely will be) in active use for a long, long time. Maybe i'll switch to something more energy efficient at some point but i'd have to get that practically for free (20W vs. 10W or something... not really worth the time of a new setup or paying actual money on hardware).