All my dot files and wallpaper here.
It's been quite performant with wifibox. It proof itself to be more than just a workaround for having better wifi support by using a virtualized minimal Alpine Linux in Bhyve to take advantage of the Linux wifi driver support, it sorta became another security layer by encapsulating my network traffic behind isolated minimal Linux environment that if compromised can protect my main box from and a possible invasion confining the attacker within a stripped out Alpine box that only has what is needed to run wpa_supplicant and the wifi driver, it doesn't even has apk btw.

After GNU diff3 was replaced by a port from OpenBSD, the only GPLed software left in FreeBSD base was dialog which has largely been replaced by Alfonso Siciliano's Herculean job on bsddialog.  Now finally that too has been removed in 16-CURRENT, and the entire GNU subtree has been retired!

https://github.com/freebsd/freebsd-src/commit/134a4c78d070f8c4ea43a060a7ae28d22ac39558

https://reviews.freebsd.org/D55424

This looks like a first among the major (32/64-bit) *BSDs, though I believe the 16-bit *BSDs like RetroBSD, DiscoBSD and Granddaddy 2.11BSD (the only actively maintained member of the original Berkeley family) have always been GPL-free.

OpenBSD does not allow new software bound by the GPL into its base system, although according to https://www.openbsd.org/policy.html

>For historical reasons, the OpenBSD base system still includes the following GPL-licensed components: the GNU compiler collection (GCC) with supporting binutils and libraries, GNU CVS, GNU texinfo, the mkhybrid file system creation tool, and the readline library. Replacement by equivalent, more freely licensed tools is a long-term desideratum.

The NetBSD Project says https://www.netbsd.org/about/redistribution.html

>Though we would like all of the software that we distribute to be covered by a Berkeley-style license, we can't make other people change their license terms, and we don't have an infinite amount of time to rewrite all of the software that we need.

So FreeBSD removing the last GPLed software is a big achievement. This is actually a week old (7 July) but I thought it would be cause for wider celebration than I've seen so far!! Kudos to the developers. After all, it's been 33 years so what's an extra week!!!

Edited to add: Interestingly the GNU subtree back in FreeBSD 1.0 even included GNU Chess in base, which shows how priorities have shifted since then! https://github.com/freebsd/freebsd-src/tree/releng/1/gnu

Some things still aren't right, and the meson build file has a few hacks I'd like to clean up, but I've gotten somewhere.

As you could tell this is FreeBSD, which I am triple booting it with Windows 11 and Linux Mint.

Time to upgrade your systems again! Unlike last week, this isn't another set of Nicholas Carlini / Claude Mythos Preview discoveries (see https://www.reddit.com/r/freebsd/comments/1svvco2/freebsd_security_patches_for_two_more_claude/ for those two).

But there were three CVEs found by AISLE Research, another firm who use AI models to analyze codebases, find vulnerabilities and propose fixes. Clearly we'll be hearing a lot more about the role of AI in cybersecurity. https://aisle.com/about-us

New security advisories: https://www.freebsd.org/security/advisories/

FreeBSD-SA-26:17.libnv - Heap overflow in libnv, credit: Mariusz Zaborski (CVE-2026-35547). libnv is a general-purpose library designed for storing and exchanging sets of name-value pairs. This library can serve as an Inter-Process Communication (IPC) framework, enabling processes to exchange data and file descriptors. For example, it is used in libcasper to establish communication between privileged and unprivileged processes. Additionally, libnv can function as an interface for communication between userland and kernel. When processing the header of an incoming message, libnv failed to properly validate the message size. The lack of validation allows a malicious program to write outside the bounds of a heap allocation. This can trigger a crash or system panic, and it may be possible for an unprivileged user to exploit the bug to elevate their privileges.

FreeBSD-SA-26:16.libnv - Stack overflow via select() file descriptor set overflow, credit: Joshua Rogers of AISLE Research Team (CVE-2026-39457). When exchanging data over a socket, libnv uses select(2) to wait for data to arrive. However, it does not verify whether the provided socket descriptor fits in select(2)'s file descriptor set size limit of FD_SETSIZE (1024). An attacker who is able to force a libnv application to allocate large file descriptors, e.g., by opening many descriptors and executing a program which is not careful to close them upon startup, can trigger stack corruption. If the target application is setuid-root, then this could be used to elevate local privileges.

FreeBSD-SA-26:15.dhclient - Remotely triggerable out-of-bounds heap write in dhclient, credit: Joshua Rogers of AISLE Research Team (CVE-2026-42512). dhclient(8) is the default IPv4 DHCP client used on FreeBSD. It is responsible for contacting DHCP servers on a network segment and for initialising and configuring network interfaces based on received information. When processing a DHCP offer, dhclient passes various parameters provided by the server to dhclient-script(8). DHCP options, as documented in dhcp-options(5), are passed via the environment. As dhclient is building an environment to pass to dhclient-script, it may need to resize the array of string pointers. The code which expands the array incorrectly calculates its new size when requesting memory, resulting in a heap buffer overrun. A specially crafted packet can cause dhclient to overrun its buffer of environment entries. This can result in a crash, but it may be possible to leverage this bug to achieve remote code execution.

FreeBSD-SA-26:14.pf - pf can overflow the stack parsing crafted SCTP packets, credit: Igor Gabriel Sousa e Souza (CVE-2026-7164). pf is an Internet Protocol packet filter originally written for OpenBSD. SCTP is a transport protocol with multihome support. pf parses SCTP packets to discover additional addresses for SCTP endpoints, allowing it to create states allowing connections between these additional addresses. Incorrect packet validation allowed unbounded recursion parsing SCTP chunk parameters. This can eventually result in a stack overflow and panic. Remote attackers can craft packets which cause affected systems to panic. This affects any system where pf is configured to process traffic, independent of the configured ruleset.

FreeBSD-SA-26:13.exec - Local privilege escalation via execve(), credit: Ryan of Calif.io (CVE-2026-7270). execve(2) is a system call is used to launch an executable image, including scripts prefixed with a path to the interpreter. The system call takes a path to the image as a parameter, followed by extra arguments and environment variables to be passed to the new image. An operator precedence bug in the kernel results in a scenario where a buffer overflow causes attacker-controlled data to overwrite adjacent execve(2) argument buffers. The bug may be exploitable by an unprivileged user to obtain superuser privileges.

FreeBSD-SA-26:12.dhclient - Remote code execution via malicious DHCP options, credit: Joshua Rogers of AISLE Research Team (CVE-2026-42511). The BOOTP file field is written to the lease file without escaping embedded double-quotes, allowing injection of arbitrary dhclient.conf directives. When the lease file is subsequently re-parsed by dhclient, e.g., after a system restart, an attacker-controlled field from the lease is passed to dhclient-script(8), which evaluates it. A rogue DHCP server may be able to execute arbirary code as root on a system running dhclient.

New errata notices: https://www.freebsd.org/security/notices/

FreeBSD-EN-26:10.amd64 - TLB invalidation bug on AMD systems with INVLPGB (Intel and non-x86 systems are not affected)

FreeBSD-EN-26:09.tzdata - Timezone database information update

FreeBSD-EN-26:08.pf - Incorrect duplicate rule detection for automatic tables

This is my desktop. I use ctwm as my window manager. I have Freebsd Debian and Kali Linux as my guest Vms plus many more. My FreeBSD guest has ctwm window manager like my host. Debian has mate and Kali has xfce. I am also using tiger vnc viewer. I like FreeBSD as a desktop because I get near native performance from all my guests using vm-bhyve. I always believed that all Operating Systems have their purpose. Questions, comments and suggestions are welcome. Any feedback is appreciated. Have a great week.

De acordo com https://www.freebsd.org/usergroups/

>O Grupo Brasileiro de Usuários FreeBSD (FUG-BR) www.fug.com.br/ é um grupo de usuários voltado para a língua portuguesa, com o objetivo de ajudar usuários brasileiros do FreeBSD a encontrar suporte e artigos sobre o FreeBSD em português. Mantemos alguns projetos, como o FreeBSD LiveCD https://sourceforge.net/projects/livecd/. Atualmente, o grupo tem mais de 800 membros e nossa lista de discussão recebe uma média de 80 mensagens por dia. Para se inscrever na lista de discussão do FUG-BR, visite https://www.fug.com.br/mailman/listinfo/www

Agora o site está fora do ar. O site da lista de discussão também está fora do ar. O LiveCD está inativo há 11 anos.

O FUG-BR se dissolveu? Ou ainda funciona, mas com outras informações de contato, como um novo site ou uma conta em alguma rede social? A lista de discussão foi substituída por um grupo no WhatsApp ou Telegram? Ainda há encontros, palestras ou convenções?

Se o FUG-BR estiver inativo, irei removê-lo de https://www.freebsd.org/usergroups/

The Bun toolkit for JavaScript and TypeScript apps added FreeBSD x86_64 and aarch64 as a cross-compile target today: https://github.com/oven-sh/bun/pull/29676

This closes the long-running (since 2022!) issue requesting FreeBSD support: https://github.com/oven-sh/bun/issues/1524

This is good news for Claude Code users on FreeBSD, who had been left with no obvious path forward after Anthropic switched away from npm to a native installer: https://stevengharms.com/posts/2026-03-04-freebsd-users-we-need-to-talk-about-claude-code/

Currently FreeBSD users must rely on the Linuxulator to run Claude Code: https://github.com/anthropics/claude-code/issues/30640#issuecomment-4227236808

>Hey folks, a couple updates on where we are with Claude Code on FreeBSD:

>Starting with Claude Code 2.1.101, you can run Claude Code under Linuxulator with this additional env var: BUN_JSC_useBBQJIT=0 claude

>Regarding a native FreeBSD build - a proper port means getting Bun building on FreeBSD. We're not quite there yet, but would like to get there in the future. For now you'll have to rely on Linuxulator.

>Please continue providing feedback in this issue tracker. Thanks for using Claude Code!

Now Bun has added support, there's a chance of a native FreeBSD build.

Both NetBSD and FreeBSD grew out of the community that had developed around the UPK (Unofficial Patch Kit) to 386BSD ("Jolix"). One cause of the split was impatience among the NetBSD founders at the 386BSD release schedule, and the clunkiness of maintaining a list of patches (see Theo de Raadt's comments). They preferred to start their own repository and release their own improved OS, based on version 0.1 of 386BSD plus patches, as NetBSD 0.8 in April 1993. The bulk of the UPK community were more willing to give the Jolitzes a chance to release an interim "0.5" version of 386BSD which would incorporate their patches, but eventually gave up on waiting (unfortunately relations with the Jolitzes had badly soured) and released FreeBSD 1.0 in November 1993. There were some other differences - the NetBSD group were interested in making their code portable to other platforms, the FreeBSD group cared more about performance on 386 (see brief history by Marshall Kirk McKusick). But there was an obvious question of whether they would be better to combine efforts again.

Obviously, negotiations to bring the two projects back together ended unsuccessfully. Last year I posted for help finding the "no FreeBSD/NetBSD merger" announcement, which produced some interesting recollections but no documentary evidence of merger negotiations having taken place. However, after a bit more digging around I've finally found the following in comp.os.386bsd.announce dated Nov 14, 1993: https://groups.google.com/g/comp.os.386bsd.announce/c/0fDtri4DFo4

The Unix Heritage Society have an archived copy: https://web.archive.org/web/20050210210259/https:/minnie.tuhs.org/cgi-bin/newsread?23856

Incidentally that's less than a fortnight after the the big FreeBSD 1.0 release announcement in the same group, so bear in mind this was still very early days, the projects had not diverged nearly so far apart as they are now, and so at a technical level a merger might still have been feasible - though personality clashes and different goals made that a much less practical possibility! It's interesting there were such existential discussions about the future of FreeBSD taking place even during that busy period around the initial release. https://groups.google.com/g/comp.os.386bsd.announce/c/5OphJ9DEU_U

Status on discussed merge between NetBSD and FreeBSD

This statement is being released in hope of putting to rest some of
the general questions and rumors currently floating around in respect
to the long discussed merger between the FreeBSD and NetBSD groups.

Merge
-----

Due to various problems, and in the face of fundamental differences of
opinion regarding future goals and design strategies, all merger talks
between the groups have been suspended and the proposed merger
postponed indefinately.

The FreeBSD and NetBSD groups will not be merging at any point in the
near future, and each group will be pursuing its own schedules and
delivery dates for future release.


What this means to you
----------------------

Despite various accusations and counter-accusations recently levied in
some of the comp.os.386bsd.* newsgroups, both operating systems have
reached the point where they are both very useful (and relatively
stable) development platforms for the Intel architecture, and no one
would be wrong in chosing either of the two offerings.

The currently outstanding technical differences between the two
systems will also, it is quite likely, continue to shrink with time
and both systems will probably seek their own unique areas of
differentiation outside the realm of adding features to the basic
kernel. Neither system plans to stand still over the next 6 months,
and each has a reasonably large enough user base to ensure that new
ideas, corrections and general clean-up work will continue [in both
camps] for some time to come.


Wouldn't a merge have been better?
----------------------------------

There is no question that work duplication and other technical issues
would have been avoided or made simpler under a merge, but for various
reasons it has nonetheless remained outside the realm of practicality;
please remember that what looks very simple from an outsider's point
of view is often anything but. In any case, work will still continue
apace in both camps, and history has generally shown that a little
"competition" has never hurt anyone when it comes to providing
motivation for improvement and forward movement. We tried to
negotiate a merge, it didn't work, so we have to cut our losses and
move forward. End of story.


Is the matter truly closed?
---------------------------

Yes. Please don't bombard us with email saying "Please merge!" or
"Why can't you merge? Why?!?" - believe me, we've gotten every
possible variation on the theme you might imagine, and we've done our
best to explain in more emails than we can count, so kindly do us a
favor and don't send us even more. We need to get on with our work on
FreeBSD, and such things only sap our time and hinder our progress.
To answer the next question: Conversations on this matter to date
have been, of necessity, constrained to private email due to the fact
that the situation has always been somewhat volatile, and public statements
concerning the inner workings of the merge negotiations while they were
in progress would have made them even more difficult.


We also hope that this statement will help put an end to some of the
unfortunate (and wholly unnecessary) public bickering between the
two groups. We're two groups, providing BSD technology to the world
at large for free and at considerably cost to ourselves in terms of
time and energy, so the last thing we need is the ball-and chain of
internecine warfare attached to our feet - it only aggravates all
of us and delays the progress of your favorite operating system!

Please help by cooperating with all of us in trying to put this
somewhat difficult time behind us, and continuing to provide the
extremely helpful feedback and assistance that has made both groups
possible (and certainly 386BSD itself, with which we also desire only
the best relations). Those who can provide common technology in a
group-neutral fashion are the most helpful of all, and we encourage
all of you to do what you can to see that both groups go forward.

This is all about free software, after all, and should not be about
ideological divisions or matters of personal ego.

Thank you!

(The FreeBSD team)

--
(Jordan K. Hubbard)  

It seems the negotiation emails have remained private. The announcement is somewhat vague on how meaningful the merger talks were, whether any serious progress was made, or what the main sticking points were beyond "fundamental differences of opinion regarding future goals and design strategies". I don't know whether any participants have fleshed out any more details in subsequent talks, interviews or writing, but would be very interested in to hear if they did. Interestingly the tone of the announcement makes it clear it's trying to put an end to rumours and speculation on Usenet but I haven't yet found the gossipy discussions it's a reaction to. I'm not aware of any subsequent attempts at a merger but it would be remiss not to mention the 2003 "FretBSD" April's fool joke by Dan Langille and Michael W. Lucas.

EDIT: found some of the gossip threads! And it turns out that the FreeBSD and NetBSD teams got as far as agreeing a "charter" for the merger, just not on whether to implement it... see https://www.reddit.com/r/BSD/comments/1ss7tdo/comment/ohu54xm/