Re: The case for FreeBSD

On Sun, 06 Feb 2005 03:37:54 -0700
Scott Long <scottl_at_freebsd.org> wrote:
 
> aspects.  As the old saying goes, FreeBSD is about performance, NetBSD
> is about platform portability, and OpenBSD is about security.
> 
> So is that still the case?  The NetBSD advocates are quick to claim
> that NetBSD 2.0 now beats FreeBSD in both performance and features.

That's not what Christos said and it's not even true. What was said and
what the benchmarks showed was that, for UP machines, NetBSD performs
better on certain microbenchmarks. Some NetBSD advocates were only too
happy to see those results and other FreeBSD people seemed to lack a
sense of humour when commenting the issue. Robert Watson posted some
interesting comments about it when the topic was discussed here.

> Fortunately, that just is not true.  There is a very long list of
> reasons why FreeBSD is an excellent operating system and an ideal
> choice for the enterprise and the desktop.  Briefly:

Christos is a NetBSD developer, so he'll have certain bias. However, and
I think I must have read a different report than you've done, he's very
honest when he acknowledges certain NetBSD limitations: the lkm system,
need for a better FS, need for better ACPI support, etc.

Both operating systems do certain tasks better than each other, and both
still have bugs.

> - GEOM provides to the storage stack what netgraph provides to the 
> network stack.  Transformations like mirroring, striping, spanning,
> and  encryption can be configured for any storage object from the
> filesystem  on up.  The vinum volume manager was recently converted to
> use GEOM and  now provides high-availability and high-reliability
> redundancy to any  storage object.  While NetBSD recently imported
> Vinum, it took the  older, less stable and less functional version
> that has since been  deprecated by its author in FreeBSD in favor of
> GEOM-Vinum.

OTOH, NetBSD has RAIDframe, which does the job pretty well, although is
not as flexible as GEOM raid classes. NetBSD obviously cannot import
gvinum if there's no GEOM layer.
 
> - Advanced network features and protocols such as SACK, NFSv4,
> SYN-cache/SYN-cookies, compressed TIME_WAIT, and accept filters allow
> for fast, secure, and scalable network operations in an

Christos also mentioned SACK as one of the features NetBSD should
incorporate into their stack.

> ever-increasing hostile and busy Internet.  Packet filters like IPFW
> and PF provide advanced filtering, shaping, and NAT sharing.  FreeBSD
> continues to run some of the busiest and most important network sites
> in the world with these technologies.

And so do NetBSD and OpenBSD (from which PF comes :)
 
> - Outstanding desktop and laptop support is provided by a number of
> technologies.  Nvidia develops and distributes native 3D drivers for

I wouldn't say outstanding, but it's true that FreeBSD and NetBSD are as
good a desktop as Linux can be.

> NetBSD 2.0 is a significant step forward for NetBSD, but the large 
> amount of stagnation cannot be overlooked.  Their claim at high 
> portability should have been leveraged years ago to make them the
> leader  in embedded OSes.  It's great that NetBSD is committed to
> supporting  legacy architectures, but how does the effort to do so
> benefit modern  architectures or encourage wider use and more adoption
> of NetBSD?

Those are not incompatible. Having clean code means it takes less effort
to port the kernel and MD userland to a new arch. Whether it's a 25 year
old VAX or a Mac Mini is not relevant. What's important is that this is
possible because the code is correct in the first place. NetBSD runs on
most modern hardware.

Supporting legacy architectures is interesting because many of those
CPUs are still used in the embedded market, which is one of NetBSD's
goals.

> And while NetBSD now supports SMP, it uses the same low-efficiency
> model  that FreeBSD used previously.  Scalability is significantly
> limited  because only one CPU at a time can access kernel services or

You are correct here. But don't forget that it wasn't their goal for a
long time. For a 2-way desktop there's not much subjective difference
between the two designs. Of course this changes when you start adding
more CPUs.

> drive  hardware devices.  The whole point of the 'SMPng' project for
> FreeBSD 5.x is to eliminate this problem and provide fine-grained
> parallelism in the kernel.  Converting the traditional BSD design to
> this model is not  trivial, but the work on this is very much alive,
> and each FreeBSD 5.x release is faster, more scalable, and more stable
> than the previous release.

Only more scalable as you add processors. In the state FreeBSD is now I
would recommend NetBSD 2.0 over FreeBSD 5 for UP systems any day, except
for cases where you need 3D acceleration or nvidia's proprietary
drivers.
 
> All of the open source BSD's have a place, whether it's OpenBSD,
> NetBSD, or FreeBSD.  Each continues to excel at what they've shown to
> be good at, and I expect the sharing and goodwill between them to

I think the point Christos wanted to make is that the old 'OpenBSD
secure, NetBSD portable, FreeBSD performer' is blurring. NetBSD, for UP
systems, is as good as FreeBSD is today.

> continue.  And in that vein, FreeBSD is still the 'silent workhorse'
> that runs corporate networks and powers advanced appliances.  However,
> it's time to drop the 'silent' part and start loudly advocating it. 
> FreeBSD is an outstanding OS, and developers and users should be proud
> of it.

Yes, the issue of advocacy. That's an area where all BSDs lack. As
annoying as some of you think Brett Glass is, he's done a lot of
advocacy work over the years. Unfortunately he also loves to engage on
endless anti-GPL rants which somehow remove value from his otherwise
good advocacy work.

As I see it, until FreeBSD 5 becomes fully stable and solves the UP
performance issue, some people will give NetBSD a try. Of course this is
good because it means both teams will improve the already excellent OSs
and users will have more freedom of choise.

Cheers,
-- 
Miguel Mendez <flynn_at_energyhq.es.eu.org>
http://www.energyhq.es.eu.org
PGP Key: 0xDC8514F1