RSA with DHE or ECDHE is a sane handshake. I would avoid DSA and ECDSA based key exchanges because they fail catastrophically with bad random number generators. For most APIs session caching is more important than a faster initial handshake.
The HTTPS only choice would annoy me a lot because I run most HTTPS services in behind a reverse proxy in a FreeBSD jail on the same host. HA proxy and nginx are still superior to most applications in regard to reliable TLS termination.
Using HTTPS by default a the right choice for a new project but offering no HTTP support (outside of a benchmark) patronizes the user.
All in all this looks like a nice way to export C APIs through HTTPS.
On UFS soft-updates have a lower overhead than soft-updates with metadata journaling. The downside of soft-updates without journaling is that it requires a background fsck to recover leaked space after unclean shutdowns. I prefer UFS2 SU (not SU+J) on FreeBSD for small systems, because SU+J is incompatible with UFS snapshots.
Btrfs has a broken by design on disk format. Btrfs went with self describing checksums inside blocks instead of a Merkle-DAG with a round robin root. In doing so they ignored existing research at the start of the btrfs project and the only fix is to change the on disk format to add the children's checkums to the parent nodes.
That doesn't sound "broken by design" to me, just less thoroughly safeguarded than ZFS but still more than almost any other filesystem. It's completely consistent with my claim that btrfs isn't trying to follow exactly in the footsteps of ZFS. (And it's not like Merkle trees don't have any tradeoffs.)
FreeBSD 8.4 is supported until 2015-06-30. FreeBSD 8.0 was released on 2009-11-25. Odd numbered minor releases and the last minor releases in a major release are supported for 2 years.
Migration two newer minor releases of the same major release preserves binary compatibility. There are ports to preserve binary compatibility with previous major releases.
Why would want to run 10 year old binaries if a compatible and improved version exists? Run FreeBSD 8.4 and 10.1 on the same hardware and perform a bunch of benchmarks. Even if none of the new features are relevant to you it offers improved performance.
Yes, that is what it says on paper, but I would submit that both 5.x and 7x were essentially EOL the day they came out.
Since 4.x there has been a huge focus on the upcoming releases. By the time the x.0 release comes out, all of the cool kids are working hard on x+1 and x+2 - you saw this especially during 8.0 and 8.1 when a lot of mailing list chatter from core developers revolved around nitty gritty details of 10.x.
By the time 7.1 came out (for instance) all new driver bug fixes, etc., stopped being applied to the 7 tree and the answer to every question was "it will be in (8/9)".
I do appreciate the fact that an 8.4 was created - it's a step in the right direction and a sign of some real understanding of the problems the end users are having with an inability to invest in FreeBSD and make long-term plans with their own platforms.
However, I still would like to see a release ... any release ... get to x.10 or x.11 - like 4 did. I even committed $50k to that end a few years ago (although I suppose that's small fries these days :)
If people would like to know my specific critiques, there was a long mailing list discussion in 2012:
I expect this would be a big deal for the appliance manufacturers (think Juniper, NetApp, Isilon) that need to support long life cycles . I'd also expect those type of companies to pony up for long term support (and they do, at least internally, with staff developers and trees)
But in an ops context, why not simply install compat<version> packages? Or worst case, run the obsolete apps in a <version> jail? With containers, I think we're rapidly approaching a point where the software that touches the hardware can evolve faster than the libraries/support around applications, and this quite frankly is awesome!
You missed the point of Mosh. SSH transfers a bidirectional stream of bytes between server and client. It uses TCP as transport. You can combine SSH with tmux to preserve your sessions as tmux sessions. If you use SSH to access your tmux session you fixed a part of the problem. Your client can now roam by reattaching the tmux session from a new SSH connection.
The other half of the problem remains: SSH transfers unmodified byte streams between client and server over TCP. On networks with high latency or high packet loss this design doesn't work. Mosh fixes this part of the problem by redefining the problem. Instead of transferring every byte in both directions it runs a terminal emulator on both sides and the problem turn into: keep the terminal emulator states in sync. The server sends patches from the last confirmed client state to the current server state to the last known client address:port pair via UDP. The client sends the user input (and pings) to the server via UDP. This design allows Mosh to skip over lost messages.