emaste

Mostly, we still have a couple of binutils hanging around:

- ld.bfd on 32-bit powerpc (should go when lld 10.0 is in FreeBSD)

- GNU as on i386 and amd64 (expected by some ports, and needed to assemble one file in the base system on amd64)

- objdump (expected by some ports, but not used in the base system)

These should be removed in FreeBSD 13.0. More details are on our Wiki, https://wiki.freebsd.org/GPLinBase

In fact for the vast majority of FreeBSD users (those on i386 or amd64), this happened years ago. Old GCC was kept in the tree for some Tier-2/Tier-3 archs (like MIPS), and is now removed because it's no longer used for those.

The mic doesn't work yet, actually an array of MEMS mics and needs firmware for an onboard DSP. The trackpad driver isn't yet in the tree and needs to be built separately. Overall it provides a decent experience for someone with a bit of skill.

There are certainly some, but "most" is unsupported by evidence.

I've got a Lenovo X1 Carbon 7th gen for FreeBSD development; there are many options besides ancient hardware. Buying a non-name $200 laptop isn't likely to result in a good experience, but if you're willing to do a little research there are many good options.

As I've said elsewhere, that document is a combination of useful tidbits, outdated information, and unactionable (and often incorrect) commentary. As long as you can identify the useful bits and ignore the rest it might help you.

Netflix has used Linux in EC2 for their C&C infrastructure and FreeBSD on their OCA content serving appliances since the beginning.

What about vsyscalls?

Exactly this. I use FreeBSD exclusively for my development, but there are a few pieces of proprietary software that are only available as Linux binaries (like FPGA toolchains), and having a viable Linux ABI layer means that I do not need to resort to having an entire second operating system in a VM or another machine.

TLS keeps your viewing history private from third parties (e.g. your ISP).

What's required for something to be a shell? IMO a minimal shell would have some command line editing and parser, the ability to launch applications, job control, scripting ability, and I/O redirection. These can all be done in the context of a Capsicum-sandboxed shell, where the applications that can be run, and files that can be read/written by the shell, are only those explicitly made available to the shell.

This isn't about nc's pledge call, this is about the thing that might call nc. A shell that is prevented from calling socket or connect, but can exec nc, is still able to establish a network connection.

"Towards oblivious sandboxing with Capsicum" describes a capability-aware shell: https://www.engr.mun.ca/~anderson/publications/2017/towards-...

Al Viro's a long time Linux kernel developer with an interest in at least filesystem and related code.

FreeBSD's patch runs red, a change we picked up from DragonFly BSD. That said OpenBSD's change to internally handle ed-style diffs is the best approach and I expect FreeBSD will migrate to that.

I think the long-standing impression left by 5.0 (despite carrying explicit warnings about being appropriate for early adopters) carries a good lesson for us: this sort of lore is surprisingly sticky. It doesn't matter that 5.0 was very much an anomaly that wasn't repeated, and that recent .0 releases were very stable. I suspect end-users like John are going to avoid .0 releases for as long as they use FreeBSD.

> The most frustrating thing for me are the many Bugzilla entries for issues that I'm having, with patches, that are sitting there for years. For example this one https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=25986 which was open for 14 years before it became CVE-2015-5358

That one is a particularly disappointing and egregious example, but highlights the problem we have with stale PRs and patches. There are a number of folks in the FreeBSD community working on triaging old (and new) PRs, but it's slow going and a mostly thankless task.

If you have other cases of issues that have existing PRs and/or patches please feel free to let me know (email in profile) and I'll try to find out why it's stalled and if someone can help out.

The FreeBSD Foundation's projects update from earlier this year has an introductory summary: https://www.freebsdfoundation.org/blog/february-2017-project...

> It is very appropriate that you remember the 4.x days like that since that is the last time there was a long term, stable target for FreeBSD development (and investment).

> Unless your organization, after wasting a year and tens of thousands of dollars on 5.0, has implemented a SOP to never use the x.0 of FreeBSD.

The important thing to keep in mind is that these are two consequences of the state of the FreeBSD tree in the early 5.x days. There's no question the first couple of 5.x releases had a great number of stability and other issues, and I can certainly understand that experience leading to an approach of "never use a .0 release." But it is precisely because early 5.x was in such bad shape that 4.x continued to receive ongoing development for so long.

This is very similar to an idea introduced in FreeBSD's Capsicum sandboxing framework[1] some time ago. Google's David Drysdale proposed a patch in 2014 to add this to Linux but it didn't go anywhere; I'm hopeful that this time Linux will add this support.

[1] http://www.cl.cam.ac.uk/research/security/capsicum/papers/20... [2] https://lkml.org/lkml/2014/11/4/218

Many FreeBSD utilities support a --libxo flag that produces structured output, although there isn't special handling in shells yet.

    % ls --libxo json
    {"__version": "1", "file-information": {"directory":[{"entry": [{"name":"bar"}, {"name":"foo"}]}]}
    }
    % ls --libxo xml  
    <file-information __version="1"><directory><entry><name>bar</name></entry><entry><name>foo</name></entry></directory></file-information>

I ordered a pair of SD cards from a FBA Amazon seller which turned out to be counterfeit. I used Amazon's contact form to report these, and was told to just initiate a return.

I think I chose "Item not as described" as the reason in a drop-down, and entered "Counterfeit" in a comment box, but someone later changed it to some benign-sounding reason. I got a refund on my credit card, but now have the impression that Amazon just does not care. That experience and stories like this here convinced me to first look elsewhere when I need something.

Part of the reason this is feasible is that a number of dependencies were already ported to CloudABI -- from the blog post:

    leveldb
    boost (though boost::filesystem is problematic)
    libevent
    LibreSSL

Ed Schouten's blog post on porting LevelDB is at https://nuxi.nl/blog/2017/02/18/porting-leveldb-to-cloudabi....

This Bitcoin porting blog post provides some good insight on the challenges inherent in porting existing software to a strong sandbox.

I'm sorry that we seem to be talking past each other. I don't disagree with what you write, my point is only that the reproducible builds effort has no real effect on aspects of it (such as binary diversity).

Of course there's a lot more that needs to be done to prevent or detect malfeasance, and while it's related, it's beyond the scope of the reproducible builds effort.

> That's a red herring. The diversity I referred to came from compiler transformations that provably enhance security

No. The work to get to a state where packages build reproducibly, in general, consists of removing timestamps, providing stable sort order for inputs, and similar cases. In the vast majority of cases the only diversity in a distro's package set comes from these sorts of differences. If addressing these cases results in a reproducible build, there was no meaningful diversity to begin with.

> The other problem is that making all binaries come out equal creates more of a monoculture that aids attacks on endpoints.

This is a red herring, for two reasons. First, even if the build is not reproducible, the distribution produces packages from some source code and those packages are fixed. If one is installing a distribution's binary packages there's no more or less of a monoculture if that package can be reproduced.

Second, the sources of non-reproducibility we're trying to fix here come from things like timestamps embedded in the binaries, arbitrary directory file ordering, etc. These provide little to no meaningful diversity in the resulting binaries anyhow.

Having the ability to reproducibly build packages does not preclude the application of tools or techniques to introduce diversity in the compilation process or otherwise obfuscate built binaries on one's own system.

There's a fairly comprehensive list at https://reproducible-builds.org/docs/. Debian has a detailed list of reproducibility issues and affected packages at https://tests.reproducible-builds.org/debian/index_issues.ht...

> not due to morals, but due to it being the best option for themselves

Indeed, and this is why the same thing happens in the BSD world. There are many examples of large and small companies, competitors, working on the same parts of FreeBSD.

Enlightened companies contribute to Free and Open Source software because it's in their best interest, not directly because of the license. Conversely, there are countless examples of companies who don't think it's in their interest, and willfully violate the GPL.

I have several Lenovo X220s running FreeBSD and am very happy with them. Inexpensive, good keyboard, sufficiently fast, good battery life, good expandability and availability of replacement parts.

In FreeBSD we have a long history of including metadata in commit messages (bug reference, sponsorship information, reviewer list), and introduced Phabricator for code reviews a while ago. So you can easily find Foundation-sponsored commits and for many of them observe the review history.

If using the git mirror a command like git log --since=2016-01-01 --grep 'Sponsored by.*FreeBSD Foundation' will show the Foundation-sponsored commits in 2016.

Here are a few recent examples: r310702 btxldr: process all PT_LOAD segments, not just the first two https://reviews.freebsd.org/D8929 This was a tiny change of mine, removing an 18 year old assumption to allow us to build the FreeBSD base system with LLVM's LLD linker. Reviewed by a Foundation employee and a FreeBSD (and Illumos) community member.

r310617 Make knote KN_INFLUX state counted https://reviews.freebsd.org/D8898 Reviewed by a FreeBSD developer working at Isilon.

r310371 bhnd: remove srand() to ensure deterministic output https://reviews.freebsd.org/D8857 Another one of mine as part of the Reproducible Builds effort. Reviewed by the original author of the affected driver.

These are small, uncontroversial fixes, but demonstrate the approach the Foundation strives to take with all development work. Also being able to drive longer-term projects and maintain subsystems over long timescales is a significant advantage of having funded developers on staff.

r310154 Add support to read the _CLS entry if it's present https://reviews.freebsd.org/D8721 A commit from a Foundation project grant recipient, part of adding ACPI support along with the FreeBSD/arm64 porting effort. Reviewed by a long-time FreeBSD committer and core team member. The Foundation drove the overall arm64 porting effort. Cavium (an ARM CPU licensee) and ARM helped contribute to the initial porting effort, which was generally reviewed with a similar approach.

r301172 Import NetBSD's blacklist source from vendor tree https://reviews.freebsd.org/D5912 The Foundation provided a grant to port NetBSD's blacklistd daemon to FreeBSD. The initial work here was reviewed by an idependent, long-time FreeBSD committer.

The Foundation's development projects have no special status - work is still subject to the communities norms and standards. If there were to be a dispute over a proposed project or change the final authority rests with the elected core team. (The current core team includes some Foundation members, but a minority position.)