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.

This is a longstanding tradition from FreeBSD. A list of our commit message trailers: https://docs.freebsd.org/en/articles/committers-guide/#_incl....

"Sponsored by:" search in FreeBSD commit messages: https://freshbsd.org/?q=%22Sponsored+by%3A%22

I suspect your question is essentially "why is this 14.0, and not 13.3?" And the answer to that question is that this is a new release from our development branch, not an update to an existing branch used for the 13.x releases.

FreeBSD 14.0 represents over two and a half years of feature development, stability and security improvements, and bug fixes. Some of these changes were cherry-picked into the stable/13 branch and were included in the FreeBSD 13.1 and FreeBSD 13.2 minor releases built from there.

A sibling comment notes that APIs or ABIs may change between major versions. This is true, but this is not the reason for a new major version. Rather, ABI and API changes are allowed during the development cycle on the main branch, but are not cherry-picked into the existing stable branches.

I have a proposed change to include in the release notes some significant changes that happened to have been merged into 13.x already, and so far have been excluded from 14.0's notes: https://reviews.freebsd.org/D42546

I'm sure Colin's results can be reproduced, but it will take some effort. Colin has been doing a lot of work so that Firecracker can boot FreeBSD -- see https://www.daemonology.net/blog/2022-10-18-FreeBSD-Firecrac... for an introduction -- and that is not yet all available in Firecracker "out of the box."

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?

The blog post offers the linked reply to support the claim that FreeBSD "blatantly disregards security in favor of performance and appeasing their enterprise consumers."

> Many of the claims on this page are supported with links to commits, mailing lists posts, etc

Their links to commits, mailing list posts, etc., are cherry-picked and taken out of context to present their view.

For one example, they suggest that the FreeBSD community is unwilling to make changes to improve things, and say "some of their users like it that way though", linking to https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/01....

If you actually read the thread that response is taken from (starting at https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/01...) you'll see a wholly different picture: a FreeBSD developer proposed a change, there was general agreement with a small amount of opposition including the cherry-picked message, and the change was made.

The FreeBSD src git repo has hundreds of thousands of commits, and anyone can post to mailing lists, so of course it's possible to find examples of mistakes being made, or misguided posts from developers or users.

I very much welcome constructive criticism and ideas for improving the security landscape within FreeBSD.

tcp_wrappers is still there because it provides functionality not otherwise available that is still used, and has a relatively small impact on the attack surface.

That's not true - it is in all supported releases, but not enabled by default. It will be enabled by default in the upcoming 131.1

The linked blog post gives the impression that little has changed, but it is very much not the case.

Taking a look at the first section, "OpenSSH Modifications" - rather little of it is current. With respect to ciphers disabled by default in upstream we may follow along in main but leave them enabled in a stable/release branch, in an attempt to avoid breaking existing users while deprecating increasingly insecure options over time. We do indeed add support for tcp_wrappers back in. With respect to the base system I think the rest of the section is not applicable.

It used to have a section at the bottom that described changes made in FreeBSD (negating some of the points made above), but it has since been deleted.

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.

Previous submissions (that have comments):

  https://news.ycombinator.com/item?id=11314648
  https://news.ycombinator.com/item?id=11318508
  https://news.ycombinator.com/item?id=12484248
  https://news.ycombinator.com/item?id=16008688
  https://news.ycombinator.com/item?id=20363705

Please share an example.

FreeBSD 13.0

Previous submissions (that have comments):

  https://news.ycombinator.com/item?id=11314648
  https://news.ycombinator.com/item?id=11318508
  https://news.ycombinator.com/item?id=12484248
  https://news.ycombinator.com/item?id=16008688
  https://news.ycombinator.com/item?id=20363705

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.

This is quite far off the mark.

Many companies using FreeBSD, including Juniper, NetApp, Netflix, Netgate (pfSense), iXsystems (TrueNAS), Dell (Isilon) contribute significant code to FreeBSD. It's very expensive to maintain long-lived changes from upstream, so there's a large incentive not to do so. Code that's "not contributed back" is largely code that isn't suitable for upstream anyhow - because it is incomplete, limited in scope, etc.

Looking at "Sponsored by" tags on the last 6 months of commits to FreeBSD I see the following:

  The FreeBSD Foundation
  Netflix
  Rubicon Communications, LLC ("Netgate")
  Chelsio Communications
  NetApp, Inc.
  Mellanox Technologies // NVIDIA Networking
  Innovate UK
  Klara, Inc.
  Diablotin Systems
  Dell EMC Isilon
  iXsystems, Inc.
  Citrix Systems R&D
  Axcient
  Netflix, Inc.
  DARPA
  Alstom Group
  Eldorado Research Institute (eldorado.org.br)
  Ampere Computing
  Marvell
  Stormshield
  Amazon, Inc.

(and a long list of entries with one or two commits each)

There's a backlog of work that contributors would like to get into FreeBSD; a limiting factor is availability of mentor and reviewer time to guide contributors through the process and iterating on bringing the code into a committable state.

The difference is that binary packages for Tier-2 and lower are on a best-effort basis, and might be more or less out of date depending on the available package build hardware. For arm64 we now have multiple high-end arm64 servers and can guarantee packages will be built in a timely fashion for all supported branches.

Ed Schouten presented "Running CloudABI applications on a FreeBSD based Kubernetes cluster" at EuroBSDCon 2017. Some really cool ideas, it's unfortunate that it didn't go further. https://www.youtube.com/watch?v=akLa9L5O0NY

Tylenol / acetaminophen is not an NSAID.