The BSD news will continue until morale improves. I missed this two months ago, but Baptiste Daroussin, creator of pkg and poudriere, is working on a service manager for FreeBSD called rcd.

rcd(8) is a service manager daemon called by init(8) (in place of /etc/rc). It reads service definitions from UCL unit files (/etc/rcd.d/*.ucl), builds a dependency DAG, and starts services in parallel. After boot completes, it forks to background and stays running as a supervision daemon (automatically restarting failed services and accepting control commands via a UNIX socket).

↫ Baptiste Daroussin

It’s fully backwards compatible, and works on any existing FreeBSD system without having to make any modifications to rc.d scripts or configuration files. In fact, you can install it on a running system, make zero changes to your files, and reboot to use it, which is quite impressive. The most immediate benefit is, of course, faster boot times, but you’ll also get several other benefits already found on similar systems like Solaris’ smf.

There’s a migration path in place, with a hard promise to maintain compatibility with rc.d scripts for as long as needed. This gives maintainers as much time as they need to convert to rcd‘s own unit files.

Yesterday we had the final maintenance release for the NetBSD 9.x series, and today we have FreeBSD 14.5 entering the scene.

Since this release is occurring late in a legacy stable branch, there are few new features; rather, the focus is primarily on maintenance. As such, changes since 14.4-RELEASE consist mostly of bug fixes, driver updates, and new versions of externally-maintained software.

↫ FreeBSD 14.5 release announcement

The adventurous among us are already on the 15.x branch, but those of us running mission-critical systems are most likely still rocking 14.x, and for you, this is a must.

A rather unusual announcement was made late last night: the FreeBSD project has frozen their ports repository. For more than 48 hours now, no changes have been accepted or made to the tree, and here’s why.

A 150MB binary file was recently committed to the ports tree and, as a result, core@ made the decision to implement a temporary freeze of the ports tree in order to implement some clean up efforts. The commit in question severed our ports tree mirroring to github.com due to their filesize hard limit of 100MB, and introduced a blob of questionable licensing into the repository history.

↫ Kyle Evans in freebsd-announce

While FreeBSD’s ports tree is not hosted by GitHub – it’s merely mirrored there – the FreeBSD team believes the community values the GitHub mirror too much, and as such, steps had to be taken to fix this. Ports has not been compromised and users’ systems do not appear to be at risk in any way due to this occurrence, which is good news.

Curiously, the official announcement makes no mention of which 150MB file, exactly, was committed to ports, but it didn’t take for people long to pinpoint the offending commit (screenshot). It turns out someone committed the entire github-copilot-cli Linux binary to ports, as part of the github-copilot-cli port. This FreeBSD port is effectively a way to easily install and run this tool on FreeBSD using Linuxulator, FreeBSD’s Linux compatibility layer that allows you to run unmodified Linux binaries on FreeBSD.

It’s important to note this FreeBSD port is not actually a port of the Linux version of github-copilot-cli to FreeBSD; the FreeBSD “port” merely acts as a setup script to run the unmodified Linux binary using Linuxulator. It’s not a “real” port because the tool isn’t open source and its license doesn’t allow for modifications. That’s why the announcement specifically mentions “questionable licensing” – github-copilot-cli is licensed under some custom license specifically made for this tool, and is not open source.

Anyway, for whatever reason, the maintainer of this FreeBSD port accidentally made a commit that added the actual, full 150MB Linux binary to FreeBSD ports. I’m assuming that under normal circumstances, building and installing the github-copilot-cli FreeBSD port would merely download the binary off GitHub and set Linuxulator up so that it could run it. Mistakes happen, and since there’s clearly nothing malicious going on, there’s not much to worry about. In fact, this may lead to new checks and balances to prevent this from happening in the future, which would be good news.

The FreeBSD team is working on rolling back, fixing the issue, and investigating how this could have happened. Ports is still frozen at the time of writing, but I’m sure we’ll have a more detailed account soon.