emaste

As is often the case it depends on the specifics of the application and on those building a solution. As far as raw performance is concerned FreeBSD performs very well.

Netflix gets nearly 100Gbps from storage out the network on their FreeBSD+NGINX OCA appliances. Some details in the "Mellanox CDN Reference Architecture" whitepaper at http://www.mellanox.com/related-docs/solutions/cdn_ref_arch..... The closest equivalent I've found on Linux was a blog post on BBC streaming getting about 1/4 of the performance.

Chelsio has a demo video (with terrible music) using TCP zero copy of 100Gbps on a single TCP session, with <1% CPU usage https://www.youtube.com/watch?v=NKTApBf8Oko.

At SC16 NASA had a "Building Cost-Effective 100-Gbps Firewalls for HPC" demo, using FreeBSD and netmap: https://www.nas.nasa.gov/SC16/demos/demo9.html

Also have a look at https://wiki.freebsd.org/Capsicum, which has links to many examples of already-Capsicumized applications and work in progress.

In 11.0-RELEASE-p1.

I merged them here: https://svnweb.freebsd.org/base?view=revision&revision=30637...

> And if you do need to build for multiple targets, you just run the binutils tools multiple times

The question here is whether you can run the same tool (the same binary) for two different targets, or if you have to run a different version of e.g. ld built specifically for each target.

> when I discovered the toolchain didn't use GNU ld, but Mach's ld64

You can of course use GNU ld with Clang/LLVM if you so choose; this is the default on FreeBSD/arm64 today. The new point with 3.9 is that the full Clang/LLVM + lld toolchain can self-host (using the lld ELF support). ELF lld supports a significant subset of the linker script syntax, and additional functionality is being added as actual uses are found. (It's sufficient to link the FreeBSD kernel today.)

I'm sorry this issue fell through the cracks. Feel free to add me (emaste) to the CC on any bsdgrep PRs you raise or encounter.

The patch in [2] was added a bit over a month ago as a comment in a bug report about the GNU grep in the base system, so I don't think it's a good example of no one caring about bsdgrep bugs.

On occasion I search for bsdgrep bugs, and did not find the comment / patch in [2]. Thank you for pointing it out, I'll look at it when I can.

This work is being done in ZFS on Linux but will make its way back into OpenZFS/Illumos and FreeBSD.

Note that the commit linked here is a port of the Illumos Crypto Framework (ICF), which is a dependency but is not the change that actually brings native encryption.

DOS partition support was added to the FreeBSD installer over two decades ago:

    Tue Sep 7 12:02:11 1993 UTC (22 years, 9 months ago)
    Added DOS partition support and maybe badblock remappping.

https://svnweb.freebsd.org/base?view=revision&revision=408

There's a little bit of detail in this press release from Mellanox: http://ir.mellanox.com/releasedetail.cfm?ReleaseID=959350

Many different groups in the FreeBSD ecosystem have a lot of interest in some aspects systemd, launchd, etc., and patches exist for several different implementations in various states of completion. At this point though your statement is just speculation and has no basis in fact; there is no current plan to integrate this work into FreeBSD proper.

A fair statement would be "FreeBSD may eventually adopt a systemd-like approach."

That used to be the case, but Netflix started building out their own CDN a few years ago and they've migrated away from their legacy providers. Netflix is now serving about a third of US peak time internet traffic from FreeBSD.

See for example http://time.com/3901378/netflix-internet-traffic/ Note that the metric is actually downstream peak time consumer ISP traffic which is a little different than "40% of the Internet," but the fact remains that Netflix is using FreeBSD to serve a phenomenal amount of traffic.

I'm very intrigued by this as well. I tried a variety of shapes and the only ones it recognized for me were "S shaped" and "very straight."

I did get these too though:

"Your guess was extremely accurate. Is that you, Raj Chetty?"

"We’re going to be honest here: Your line was pretty odd. Did you even try?"

For reference, Colin's 2009 "Cryptographic Right Answers" blog post is here: http://www.daemonology.net/blog/2009-06-11-cryptographic-rig...

FreeBSD has supported a git mirror for years, although the primary VCS (the "source of truth") is still Subversion. A number of downstream consumers of FreeBSD use the git mirror though, and we have brought in patches from submitted pull requests.

I see this issue has been discussed on the FreeBSD lists on occasion, but I can't find it on the sshuttle list in the four years of archives I've got. I also don't see a reference to this in the README.md in the original project.

The threads I have managed to find largely amount to "it doesn't work." Are you aware of anywhere the specific details of the issue are posted (debug logs from sshuttle, packet captures, etc.)?

Avery hasn't put much effort into sshuttle for some time - you probably want Brian May's fork, which is now https://github.com/sshuttle/sshuttle

In any case, since 2011 sshuttle has supported DNS interception via a divert socket, so although it might not work today I suspect it should be somewhat straightforward to fix. I haven't looked into this yet as my only use case for sshuttle involves running it on the end host itself (typically my laptop).

Also, their Github repo is here: https://github.com/nestedkernel/PerspicuOS

Note that the Contributor License Agreement (CLA) and copyright assignment are rather different things. Google and the FSF have very different reasons for requiring their respective arrangements.

64-bit ARM as a Tier 1 FreeBSD architecture is on the roadmap. 32-bit ARM will get there too, I think, bit it's not being pushed as aggressively.

From https://openconnect.itp.netflix.com/software/index.html:

For the operating system, we use FreeBSD version 10. This was selected for its balance of stability and features, a strong development community and staff expertise. All code improvements, feature additions, and bug fixes are contributed directly back to the open source community via the FreeBSD committers on our team. We also strive to stay at the front of the FreeBSD development process, allowing us to have a tight feedback loop with other community and partner developers. The result has been a positive open source ecosystem that lowers our development costs and multiplies the effectiveness of our efforts..

It is very good that the bug was found and fixed in -CURRENT, but it's also important not to be dismissive of the issue. It is unfortunate that some recent posters are clearly confusing -CURRENT with the stable branch from which releases are cut. However, this is a very serious flaw that existed in the tree for some time, and is indeed a big concern in the FreeBSD developer community.

I can understand the terminology may be confusing to someone new to FreeBSD, but the handbook clearly documents the meaning of -CURRENT and -STABLE, and explains that -CURRENT is the "bleeding edge" of FreeBSD development.

A lot of non-Free software also disallows redistribution, so it's not permissible to put it in the binary repository. It's possible that free but not Free (e.g., zero-cost binary-only software) software could be included in the repository.

pkg metadata does include license information -- see https://github.com/freebsd/pkg/issues/20, but I am not sure of plans to provide user-facing control over acceptable licenses at the moment. It's a good idea though and I'll see if we can make it happen.

I agree that this is much worse than a crash if you care about your keys, and I'm not trying to suggest otherwise.

My point is that -CURRENT may be rather unstable at any given time, and is explicitly not supported. One should not be using it a production deployment where sensitive key material may exist.

There's a lot of public evidence of NetFlix's use of FreeBSD and their desire to generally stay up-to-date. I'm not aware of any credible statement that they're actually on -CURRENT though, and even if they were at some point they may not have updated since then.

They are heavily involved in FreeBSD development and I'm sure they're keeping on top of developments in -CURRENT, but I believe they are not using affected versions anywhere in production.

Or as Juli Mallett put it on Twitter, "If you can deal with FreeBSD -CURRENT crashing, you can deal with the RNG being b0rked for a few months."

This is indeed a serious issue, and I'm disappointed it was in the source tree for four months. But -CURRENT is the development branch, and is not supported by the FreeBSD security team, or supported for use in production.

From https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/c...:

FreeBSD-CURRENT is made available for three primary interest groups:

Members of the FreeBSD community who are actively working on some part of the source tree.

Members of the FreeBSD community who are active testers. They are willing to spend time solving problems, making topical suggestions on changes and the general direction of FreeBSD, and submitting patches.

Users who wish to keep an eye on things, use the current source for reference purposes, or make the occasional comment or code contribution.

FreeBSD-CURRENT should not be considered a fast-track to getting new features before the next release as pre-release features are not yet fully tested and most likely contain bugs. It is not a quick way of getting bug fixes as any given commit is just as likely to introduce new bugs as to fix existing ones. FreeBSD-CURRENT is not in any way “officially supported”.

This is a very good point, one that I missed in my followup on the FreeBSD-CURRENT mailing list. See also https://www.imperialviolet.org/2013/06/15/suddendeathentropy...