Status of FreeBSD

What is the current situation re Nix package manager on top of FreeBSD? I see the home page of the project only mentions Linux and MacOS now. From MacOS to FreeBSD it doesn’t seem like a huge stretch but on the other hand I remember reading Nix used cgroups somehow.

I don’t like where Linux is going, and I’d like to switch my own devices to BSD where possible.

1 Like

What is the current situation re Nix package manager on top of
FreeBSD? I see the home page of the project only mentions Linux and
MacOS now.

I’m dual booting NixOS and FreeBSD at the moment - pkg tells me that
only version 2.3.10_1 is packaged in repos (for reference, 2.6.1 was
tagged two days ago, though nixpkgs-21.11 is on 2.3.16 by default).
Maintenance on the repo responsible for the port[0] seems to have slowed
(last commit roughly a year ago). And, while the official install script
has its own flaws, it’s still much more cohesive than the port (which
doesn’t even make the /nix directory by default).

I’d guess that Nix on FreeBSD is in the ‘theoretically possible with
lots of manual labour’ stage. RFC 46 places (x86) FreeBSD on Tier 7: no
support, but a clear path is present. With sufficient interest and
community activity, it’s probably possible to start climbing the tiers.
(And, actually, I’ve got some free time and a FreeBSD partition today,
so I might see what packaging later versions looks like…)

I remember reading Nix used cgroups somehow.

I’m not sure this is the case, or at least it isn’t necessarily the case
in all situations - MacOS doesn’t support cgroups, and Nix runs on that!

[0] GitHub - 0mp/freebsd-ports-nix: Nix package manager port for the FreeBSD Ports Collection

3 Likes

Maybe not directly an answer to your question, but NetBSD support has recently seen some more activity: Pull requests · NixOS/nixpkgs · GitHub

1 Like

You can probably get at Nix 2.3 to build on FreeBSD. Due to a lack cgroups, sandboxing won’t work (like on macOS, for example).

The bigger problem than Nix, the package manager, is nixpkgs, the package repository. The FreeBSD stdenv has massively bitrotted over the years (mainly because we don’t build a pure FreeBSD toolchain/libc, but instead reuse whatever is found on the system). A lot of packages assume libc is built purely, so that already breaks a lot of things and the rest is probably quite broken as well, since it doesn’t see active use/testing anymore.

That being said, there has recently been interest in improving BSD support, we have decent NetBSD cross-compilation support (from Linux/macOS), with the perspective to bootstrap a pure native NetBSD stdenv in the future.

NetBSD is the easiest of the BSDs to support of course, but work on supporting FreeBSD for cross compilation has been started, but stalled a bit for now: https://github.com/NixOS/nixpkgs/pull/82131. It would be great to see more contributions in this direction, making a NetBSD / FreeBSD stdenv in the future probably would only make sense if we have the contrributors to back up the effort. For now, however, helping on BSD support sadly implies working on Linux, since the place to start is cross-compilation support.

5 Likes

NetBSD is the easiest of the BSDs to support of course

Sorry for my ignorance - why is that?

Apologies, that’s not quite obvious. I think what makes NetBSD easier is twofold:

  1. They use a GNU toolchain (albeit a patched and outdated one). In practice we were able to just use our normal GNU cross toolchain for building NetBSD packages. Today this could probably be not as important anymore, as the LLVM cross toolchain was in a much worse state when the NetBSD project was started.
  2. NetBSD emphasizes ABI/API compatibility. In particular, NetBSD (kernel) releases won’t break the syscall interface which means that binaries cross compiled from nixpkgs will keep working in the future. As I understand it, FreeBSD and in particular OpenBSD do on occasion break their interfaces, so the used libc and kernel must match. This just means more effort and maintenance is involved with supporting them, as we have more urgency to keep up with upstream and potentially need to support multiple versions of the target OS (multiple libc versions etc.).
1 Like

Thanks for the clear explanation.

In general I’d be interested in ways to organize a proper BSD effort. The problem is probably that we’d best recuit some BSD users, but for now there’s only things to be done on Linux (i.e. getting cross support ready to later cross compile the native bootstrap-tools) and we’d also need to motivate the larger community enough for the effort of course.

2 Likes

Are there any developments on this? I tried nix on FreeBSD, but I am clearly not getting anywhere…

@qyliss got NetBSD cross working, and is chipping away at NetBSD native. I did some FreeBSD cross but have yet to finish it.

3 Likes

Slightly OT, but I would find a blog post about the porting process to xBSD super interesting.

3 Likes

@sternenseemann So you don’t see anything ported to FreeBSD anytime soon ?
In case you need one more FreeBSD user, I’m available for testing though.

Hard to predict, as it could change quite quickly. Getting basic FreeBSD cross up could be a matter of a few weeks to months if someone dedicated worked on it again, I can imagine, but at the moment work has stalled for a lack of time / different priorities I think.

My worries with adding new OS / Architectures is the maintenance burden that comes with it. It is something experienced in NetBSD pkgsrc which is a package repository mainly for NetBSD but supports Linux/Solaris/MacOS/OpenBSD/FreeBSD/Haiku etc… but then comes tier in play, main consumers of the repository have the first grade quality of the packages, and other “supported” platforms regularly see breakages at the point I never found interesting to use pkgsrc outside of NetBSD :confused:

Adding more OS/Architectures combinations increase packages complexity to support them all: custom patches etc… with no clear benefit if the end result quality isn’t good enough.

Don’t get me wrong, as a BSD user, I’d be happy to see Nix there, but I’m not convinced the work involved is worth it, and I’d like to be proven wrong. :+1:t3: Getting nix to run is just a first step if you look at the whole work required that must be sustained after.

I feel in Nixpkgs, we’re in a better position to support many platforms due to the declarative nature.
The BSDs will be much less of a pain to support than macOS and we’re already managing to get that working to a usable degree (on 2 µarchs no less).

1 Like

In some way, Makefiles in pkgsrc are declarative too?

Seems pkgsrc is also reproducible since 2017 NetBSD Blog

1 Like

I think the challenge is bootstrapping a BSD / Nix subcommunity that actually uses and contributes to a hypothetical BSD support. This is not unheard of in principle, as was the case in adding support for Darwin, although the potential user base is much smaller in this case (and a proper package manager already available by default).

Any platform besides x86_64-linux already has a lesser support tier in nixpkgs today which hasn’t prevented it from being useful to users the “lesser” Darwin and Linux platforms. BSD probably only stands to benefit from the work put into multi platform support so far (especially clang and non-glibc platforms), although non-GNU coreutils may pose a new challenge. The big problem is of course finding the maintainers interested in the upkeep of the BSD support and looking into any platform specific that are sure to arise. If we don’t have that, any support we add is likely to bitrot like the FreeBSD support we nominally have at the moment.

1 Like

As an update, @Ericson2314 has been able to complete the initial cross support for FreeBSD, targeting x86_64 FreeBSD 13.0 (we are using the system tuple x86_64-freebsd13). This is available in unstable nixpkgs and NixOS 21.11

The entrypoint is pkgsCross.x86_64-freebsd and simple and portable packages likely already work. As with NetBSD, improving the coverage will probably require looking into build failures and ideally working with upstream projects improving their portability.

8 Likes