New FreeBSD 15 Retires 32-Bit Ports and Modernizes Builds (theregister.com) 32
FreeBSD 15.0-RELEASE arrived this week, notes this report from The Register, which calls it the latest release "of the Unix world's leading alternative to Linux."
As well as numerous bug fixes and upgrades to many of its components, the major changes in this version are reductions in the number of platforms the OS supports, and in how it's built and how its component software is packaged.
FreeBSD 15 has significantly reduced support for 32-bit platforms. Compared to FreeBSD 14 in 2023, there are no longer builds for x86-32, POWER, or ARM-v6. As the release notes put it:
"The venerable 32-bit hardware platforms i386, armv6, and 32-bit powerpc have been retired. 32-bit application support lives on via the 32-bit compatibility mode in their respective 64-bit platforms. The armv7 platform remains as the last supported 32-bit platform. We thank them for their service."
Now FreeBSD supports five CPU architectures — two Tier-1 platforms, x86-64 and AArch64, and three Tier-2 platforms, armv7 and up, powerpc64le, and riscv64.
Arguably, it's time. AMD's first 64-bit chips started shipping 22 years ago. Intel launched the original x86 chip, the 8086 in 1978. These days, 64-bit is nearly as old as the entire Intel 80x86 platform was when the 64-bit versions first appeared. In comparison, a few months ago, Debian 13 also dropped its x86-32 edition — six years after Canonical launched its first x86-64-only distro, Ubuntu 19.10.
Another significant change is that this is the first version built under the new pkgbase system, although it's still experimental and optional for now. If you opt for a pkgbase installation, then the core OS itself is installed from multiple separate software packages, meaning that the whole system can be updated using the package manager. Over in the Linux world, this is the norm, but Linux is a very different beast... The plan is that by FreeBSD 16, scheduled for December 2027, the restructure will be complete, the old distribution sets will be removed, and the current freebsd-update command and its associated infrastructure can be turned off.
Another significant change is reproducible builds, a milestone the project reached in late October. This change is part of a multi-project initiative toward ensuring deterministic compilation: to be able to demonstrate that a certain set of source files and compilation directives is guaranteed to produce identical binaries, as a countermeasure against compromised code. A handy side-effect is that building the whole OS, including installation media images, no longer needs root access.
There are of course other new features. Lots of drivers and subsystems have been updated, and this release has better power management, including suspend and resume. There's improved wireless networking, with support for more Wi-Fi chipsets and faster wireless standards, plus updated graphics drivers... The release announcement calls out the inclusion of OpenZFS 2.4.0-rc4, OpenSSL 3.5.4, and OpenSSH 10.0 p2, and notes the inclusion of some new quantum-resistant encryption systems...
In general, we found FreeBSD 15 easier and less complicated to work with than either of the previous major releases. It should be easier on servers too. The new OCI container support in FreeBSD 14.2, which we wrote about a year ago, is more mature now. FreeBSD has its own version of Podman, and you can run Linux containers on FreeBSD. This means you can use Docker commands and tools, which are familiar to many more developers than FreeBSD's native Jail system.
"FreeBSD has its own place in servers and the public cloud, but it's getting easier to run it as a desktop OS as well," the article concludes. "It can run all the main Linux desktops, including GNOME on Wayland."
"There's no systemd here, and never will be — and no Flatpak or Snap either, for that matter.
FreeBSD 15 has significantly reduced support for 32-bit platforms. Compared to FreeBSD 14 in 2023, there are no longer builds for x86-32, POWER, or ARM-v6. As the release notes put it:
"The venerable 32-bit hardware platforms i386, armv6, and 32-bit powerpc have been retired. 32-bit application support lives on via the 32-bit compatibility mode in their respective 64-bit platforms. The armv7 platform remains as the last supported 32-bit platform. We thank them for their service."
Now FreeBSD supports five CPU architectures — two Tier-1 platforms, x86-64 and AArch64, and three Tier-2 platforms, armv7 and up, powerpc64le, and riscv64.
Arguably, it's time. AMD's first 64-bit chips started shipping 22 years ago. Intel launched the original x86 chip, the 8086 in 1978. These days, 64-bit is nearly as old as the entire Intel 80x86 platform was when the 64-bit versions first appeared. In comparison, a few months ago, Debian 13 also dropped its x86-32 edition — six years after Canonical launched its first x86-64-only distro, Ubuntu 19.10.
Another significant change is that this is the first version built under the new pkgbase system, although it's still experimental and optional for now. If you opt for a pkgbase installation, then the core OS itself is installed from multiple separate software packages, meaning that the whole system can be updated using the package manager. Over in the Linux world, this is the norm, but Linux is a very different beast... The plan is that by FreeBSD 16, scheduled for December 2027, the restructure will be complete, the old distribution sets will be removed, and the current freebsd-update command and its associated infrastructure can be turned off.
Another significant change is reproducible builds, a milestone the project reached in late October. This change is part of a multi-project initiative toward ensuring deterministic compilation: to be able to demonstrate that a certain set of source files and compilation directives is guaranteed to produce identical binaries, as a countermeasure against compromised code. A handy side-effect is that building the whole OS, including installation media images, no longer needs root access.
There are of course other new features. Lots of drivers and subsystems have been updated, and this release has better power management, including suspend and resume. There's improved wireless networking, with support for more Wi-Fi chipsets and faster wireless standards, plus updated graphics drivers... The release announcement calls out the inclusion of OpenZFS 2.4.0-rc4, OpenSSL 3.5.4, and OpenSSH 10.0 p2, and notes the inclusion of some new quantum-resistant encryption systems...
In general, we found FreeBSD 15 easier and less complicated to work with than either of the previous major releases. It should be easier on servers too. The new OCI container support in FreeBSD 14.2, which we wrote about a year ago, is more mature now. FreeBSD has its own version of Podman, and you can run Linux containers on FreeBSD. This means you can use Docker commands and tools, which are familiar to many more developers than FreeBSD's native Jail system.
"FreeBSD has its own place in servers and the public cloud, but it's getting easier to run it as a desktop OS as well," the article concludes. "It can run all the main Linux desktops, including GNOME on Wayland."
"There's no systemd here, and never will be — and no Flatpak or Snap either, for that matter.
no systemd (Score:5, Interesting)
That alone is a reason to make sure FreeBSD will stay around. "No Flatpak or Snap either" is another.
Good to see that some people still understand what "solid engineering" means.
Re: (Score:2)
Re: (Score:3)
Re: (Score:3)
Indeed.
Re: (Score:3)
Bhyve https://wiki.freebsd.org/bhyve [freebsd.org]
Re: (Score:2)
>XLibre/no Wayland, no Rust re-writes of basic utilities,
This is sounding better and better. If Devuan ever drops the ball I guess it'll be time to go BSD.
Re: (Score:1)
I hope they're right when they and 'never will be'. On the other hand, there's that expression "never say never." Some things are happening in the world right now that I thought would never happen.
Re: (Score:2)
Without the influx of tons of Windows people (that do not get it) into the Linux space, systemd would never have been a thing. That same problem could or could not happen with the xBSDs, but it should at the very least be far away. Meanwhile, all my Devuan installations and the few remaining non-systemd Debian installations continue to run perfectly fine and with no gross security problems.
Re: (Score:1)
My PCLinuxos distros are also running just fine.
I miss PC-BSD (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
The OpenSSL library implements TLS protocols. It's not like you have to rename the library when you add support for new protocols and ciphers.
Re: (Score:2)
Re:I miss PC-BSD (Score:4, Interesting)
We're working on it!
-adrian@freebsd.org
Re: (Score:2)
Re: (Score:2)
My daily driver has been Plasma on FreeBSD for several years now.
This year I switched over to Wayland, and it's working pretty well. About as many quirks as I've seen on Linux.
I enjoyed PC-BSD back in the day, and I've used GhostBSD before. I understand the appeal of a distribution with a GUI already set up.
But it has gotten really easy to set up a GUI on FreeBSD.
My laptop's wifi is Intel AX200, which seems to be one of the best choices for FreeBSD right now.
There was a major speed boost in the iwlwifi driv
Re: (Score:2)
The bigger story (Score:4, Interesting)
Big endian support is dead. Power was always great for testing code, because you could get an old Mac off e-bay for $100 and make sure stuff worked right. Now the only Power architecture supported is little endian.
I mean, if you see computer programming as just a means to an end, that's fine, but if you see it as an art form (c.f., "The Art of Computer Programming," written by some guy) it's important to write portable code.
Re: (Score:2)
Re: (Score:3)
It's called Algol 68, not some hypothetical 18 years younger Pascal offshoot :)
The venerable Algol 68... I'm not yet sure that a compiler for the full language specification ever existed.
Re:The bigger story (Score:4, Interesting)
It's not dead, it's still showing up in weird places you don't run linux/freebsd in embedded RTOSes which borrow the freebsd networking/wifi stack.
Also PPC64 BE may be dead from the current generation of openpower chips for the bare metal hardware, but not from the VM side. There's a weird reason there's still PPC64BE and it's due to a large three letter company...
Part of the reason: 2038 (Score:2)
I believe part of the reason is the year 2038 issue. A while ago I remember seeing posts about the issues FreeBSD has/had with getting around 2038 on their system. IIRC, it was a huge effort.
Add to that most 32 bit systems are pretty much gone, I think it made sense for them to dump 32bit instead of spending resources on getting 2038+ dates working.
NetBSD did get 2038 working I think because of their HAL. So the changes may have been much easier for NetBSD. IIRC, Linux is still not 100% 2038 on 32bit sy
Re: (Score:2)
Re: (Score:3)
If you just do time() you are missing a bunch of other important interfaces, gettimeofday(2), and stat(2) along with fstat(2). The stat calls also interface with on disk data structures...
All something that can be done, but not just one trivial thing.
Re: (Score:2)
I believe part of the reason is the year 2038 issue.
Im can believe that, although it is a kind of weak reason. They could keep 32 bit FreeBSD around and make time_t a “long long”, I mean it is a typedef already isn't it? Sure it would be kind of a pain in that code that assumes it is an int or long wouldn’t work until patched, and the actual hard part would be on disk structures (like FFS inodes) very likely have 32 bits allocated (actually I think the FFS on disk structure had an adjacent unused 32 bit field, if so that one would be fix
Re: (Score:2)
im can believe that, although it is a kind of weak reason
It is not just time_t, but a lot of related things too. File Systems may very well need conversions if they used 32bit time stamps. Recompiles of all ports, some ports may need updated if they have logic surrounding the size of time_t. And Linux emulation, who knows what complications that brings to the table. I am sure I am forgetting other things too.
Re: (Score:2)
*EVERY* UNIX and UNIX-like system has to deal with the problem. But it's got nothing to do with 32-bit systems, because OpenBSD and NetBSD have it working since 2012 on 32-bit systems. Linux since 2020 (Linux supported 64-bit time_t on 64-bit platforms already, but 2020 is when 32-bit systems supported it).
It's not a si
Re: (Score:1)
Re: (Score:2)
OpenBSD has the luxury by fiat that users will accept utterly breaking API for previous versions, to say you must recompile all apps for the new 32 bit time_t; not a big deal the way the distro is put together, if you use their thousands packages you're fine, they did the work for you. OpenBSD users are fine with the "flag day break the past" approached, explained, promised and delivered.
Not the case in Linux land, utterly different situation. They promise and keep backward compatibility of 32 bit libraries. No flag day promised, threatened or allowed. Your 32 bit Linux will die in 2038, deal with it.
It is possible to preserve previous structures for compatibility while accepting changes for newly compiled software. For example to support 64-bit time_t on x86 build add the compiler flag D_TIME_BITS=64. Decades ago similar changes were made to allow for handling of large files in Linux without breaking backwards compatibility.
Re: (Score:1)
That's my article. Nice one. (Score:2)
Front page of Slashdot again wooo!
Couple of small corrections since I wrote that...
There is an Electron port and a version of VScode available.
The thing about Groff in core is really old and it's long gone.