emaste

Not quite; one FreeBSD community member who isn't a developer edited the FreeBSD wiki to suggest this, and that was picked up by a variety of tech press sources.

The comment I left on a Reddit thread four years ago still applies:

> This link gets shared around every now and then, and my response is always the same: there is some useful insight, but there's also information that's so outdated it provides no value, outright misinformation, and self-contradiction. Some of the technical points are fair, and should be and are being addressed. But the commentary is often laughably wrong. The document seems more focused on advancing an agenda than a good-faith effort at improving security in FreeBSD.

If anyone is actually interested in discussing mitigations and improved security posture on FreeBSD I'd suggest starting a thread on one of the mailing lists, but I'll also keep an eye out for feedback here and on the Fediverse.

The (original) headline is backwards; this is about Anthropic's interest in FreeBSD, not the other way around.

A lot of Linux kernel drivers are permissively licensed, or dual-licensed with a choice of GPL and a permissive license. This is especially common for vendor-developed drivers. From a hardware vendor’s perspective, broad license compatibility directly supports adoption: the more operating systems, hypervisors, and embedded environments that can incorporate the driver code, the wider the potential market for the hardware itself.

32-bit x86 CPUs haven't been made in years, companies building products based on FreeBSD switched to 64-bit x86 or to other architectures long ago. It's not that work on i386 is being done but kept in private repos and not upstreamed -- work on i386 just isn't being done at all.

Perl was removed from the FreeBSD base system over 20 years ago.

Note that the bug that is the topic of discussion here predates OpenZFS. Whether or not there has been a slide in disciplined development in OpenZFS, this bug does not support that assertion.

Not really sure how this comment relates to mine.

The FreeBSD Foundation and FreeBSD Project members have been investing in and working on improving FreeBSD security for at least the last several years. Much of that "FreeBSD – A Lesson in Poor Defaults" blog post is outdated/incorrect/conjecture.

> I did just try to use etcupdate for the 13.2-RELEASE upgrade and it hung forever trying to grep for something in /etc/default/devfs.rules

Would you be willing to submit a bug for the etcupdate issue? Or, just reply here with as much detail as you can recall about how you ran it?

> The only orgs that tend to use BSD tend to not want to give back.

This isn't true. Looking at the last year of git commits I see significant contributions from a large number BSD-using companies and organizations. Looking at the top of the list (roughly sorted by commit count) we have:

  The FreeBSD Foundation
  Netflix
  Rubicon Communications, LLC ("Netgate")
  Klara, Inc
  Juniper Networks, Inc.
  Beckhoff Automation GmbH & Co. KG
  NVIDIA Networking
  Chelsio Communications
  DARPA
  AFRL
  NetApp, Inc.
  Arm Ltd
  Axcient
  Microsoft
  Intel Corporation
  Amazon, Inc.
  vStack
  UKRI
  Innovate UK
  Stormshield
  Modirum MDPay
  iXsystems, Inc
  Instituto de Pesquisas Eldorado (eldorado.org.br)
  Citrix Systems R&D
  Dell EMC Isilon

There are a couple of (admittedly high-profile) companies that use FreeBSD in their proprietary products with limited contribution to the community, but they are very much in the minority.

Very interesting, but it looks like you're only targeting the Linux kernel right now?