FreeBSD problems and preliminary ways to solve

[Robert Watson]

On Thu, 18 Aug 2011, Vadim Goncharov wrote:

>>  everything is ``suitable'' for common tasks. And it is NOT ENOUGH
>>  to be technically better. System should be far more superior to be
>>  chosen, if it is not fancy/trendy. Yes, I belive, that FreeBSD is
>>  better than Linux (at least on supported hardware) in server tasks,
>>  more clear, more solid, etc. But it is ``only'' better, and is not
>>  enough.
>
> No. The whole message was about that FreeBSD is worse in several areas, 
> which masks out areas where it is better. If that will get fixed, we could 
> talk about is it needing to be "far more" superior or not. But not before 
> that as excuse to do nothing - no such excuse exists.

I'd point out that the key thing here is to produce, distribute, and as you 
rightly point out *make easy*, new technologies that are transformative in a 
way that makes FreeBSD compelling.  So compelling that you'd rather switch OS 
than not have it.

It's worth observing that the success of Linux (and FreeBSD) to date comes out 
of a few very basic but fundamental improvements in OS design:

- Tightly integrated networking
- Much cheaper than any competition
- Extremely stable compared to the competition

It's clear that Windows has long since caught up in the server world with 
respect to these in every practical sense (not an invitation for discussion -- 
we could talk for days) in that it is now a viable server solution in all of 
the above senses.  Which isn't to say that my multi-year uptimes for FreeBSD 
don't beat the competition, but it's clear FreeBSD/Linux no longer give you 
orders of magnitude more uptime between crashes.  I think people are also now 
much more aware of the TCO issue with operating systems, and understand that 
although open source is often better, and therefore cheaper, the lack of a 
license fee isn't the biggest issue in cost.  However, I think the lesson is 
clear: compelling features required (including things like cost and 
stability).

My own interests are largely in security, and this is what we're trying to do 
with Capsicum: make it possible to sandbox applications in a way that simply 
has never been done before, giving security that has never been had before. 
This required a new solution (although if you read our USENIX Security or 
forthcoming CACM paper, it is grounded in some quite old but promising ideas) 
that you can't find anywhere else.

It will take several years for Capsicum to meet this promise, but the first 
parts arrive in FreeBSD 9.0.  FreeBSD 9.1 is where it should get really 
exciting -- even (and especially) tools like tcpdump will run automatically 
and easily in sandboxes, something that just isn't plausibe with other 
existing sandboxing technologies.  Obviously, we hope that the rest of the 
world will adopt our APIs (and have spotted the OpenBSD folk working on this 
already, and there's a Linux port out of Google), but I hope for a bit of a 
run where you have to come to us to get this!  And being the place APIs and 
ideas like this come from is important.

There are lots of other exciting things in 9.x, and we need to make sure we 
promote them well.  I'd point out that this is an area where we also need to 
do a lot of work.  There was a lot of buzz around the release of FreeBSD 8 
when Kris was running regular competitive SMP benchmarks and showing us 
walking all over the competition.  Buzz is a critical part of selling ideas in 
open source (for better or worse), and there's no reason we can't play in that 
game a bit while maintaining our boring and staid personalities :-).

Robert