FreeBSD has serious problems with focus, longevity, and lifecycle

[Don Lewis]

On 17 Jan, Atom Smasher wrote:
> thanks john.
> 
> i've been a long-time (10+ years) freeBSD user (desktops, laptops, 
> servers, and anywhere else i can run it) and advocate (encouraging others 
> to at least check it out) and also a long-time satisfied johnco customer.
> 
> my freeBSD days seem to be coming to an end.
> 
> i bought myself a LENOVO T510 when it first came out, around early 2010. 
> it's got an i5 CPU and Arrandale GPU. it's two years old and on freeBSD i 
> STILL can't run xorg properly with it. linux has run fine with it since i 
> opened the box. last i checked, freeBSD will be support this GPU in R9... 
> or maybe R10...?
> 
> i really like freeBSD's robustness, especially compared to linux, among 
> other things. i like that freeBSD is genetically a "real" unix... what's 
> the real difference between BSD and linux? BSD was developed by unix 
> hackers porting the OS to PC hardware; linux was developed by PC hackers 
> trying to make their own version of unix. these origins are still very 
> apparent, if one knows where to look.
> 
> i like that i can set up a freeBSD bare-bones (eg secure) mail-server or 
> web-server in an afternoon.
> 
> but none of that matters if the damn thing just doesn't work.
> 
> over the last two years, and it pains me to say this, i've been running 
> linux on that T510. but it gets worse... i've been finding that i'm simply 
> more productive on that machine, and spending more time in front of it, 
> and more time getting useful things done.
> 
> i understand that it's ultimately a matter of manpower and resources, and 
> linux seems to have more momentum and "sex appeal", but i'm finding myself 
> in a real crisis of faith... the OS that i've been using and loving for 
> 10+ years seems to be dying, from any real usability perspective.
> 
> and for now, i'm slowly and reluctantly migrating towards linux.

My experience has been pretty much the opposite.

I've been using FreeBSD since 2.1 both as part of my job and also for
personal use.  I've been using Linux for work for about the last ten
years.

I'm currently running FreeBSD 8.2-STABLE for my personal computing
needs.  My experience is that the base system has been very solid and
the only problems that I run into have been with the ports.  The last
major problem that I had with the base system was USB printer support in
7.x, which was incomplete and flakey and then deteriorated to the point
of being unusable.  This motivated me to migrate to 8 which has a
rewritten USB implementation.

At work, our major software vendor only supports their software on Red
Hat Enterprise Linux and SUSE Linux Enterprise.  Since our budget is
tight, we run CentOS, which is essentially a repackaged version of RHEL.
We've been running CentOS 4.x, but are switching to CentOS 5.x now that
4.x has been EOLed.

My experience with CentOS is that new features and support for recent
hardware lags quite a bit.  A few years ago I had a motherboard that I
liked a lot that ran Fedora just fine, but CentOS lacked support for. It
took a very long time before CentOS supported NFS over TCP.  This was
especially painful because we rely heavily on NFS across a WAN to
support access to the same data from diferent sites.  In addition our
WAN is implemented using IPSEC tunnels, which have a smaller MTU, and
Linux doesn't support manually setting the MTU on a per-route basis (and
I wasn't able to get PMUTD to work).  What I observed was that the NFS
packets would first be fragmented to the default 1500 byte MTU and then
the firewall would fragment each of those packets into one large packet
followed by a tiny one.  This, along with the lack of TCP's congestion
control, was not beneficial to NFS performance ...

Bugs are also slow to get fixed.  For a very long time I had problems
with gam_server running away.  I'd frequently start top and see
gam_server pegged at 100% CPU, stealing time from my simulations.  If I
killed it, it would get respawed, and would then behave itself for a few
days before running away again.  This bug eventually got fixed, but
there's a kwin bug in CentOS 4 that still hasn't been fixed.  Every now
an then, kwin will stop working and I can no longer move windows around
my desktop.  I'm pretty sure this is fixed in a newer version of KDE,
but RHEL/CentOS tend to stick with one major version of their "ports"
forever, so I probably couldn't expect to see this fixed until I upgrade
to the next version of CentOS.  Things might be different if I was a
paying RHEL customer and was able to motivate Red Hat into back porting
patches for particular bugs.

Another "feature" that I get to enjoy on a daily basis is that the
kernel in CentOS 4 does not like my KVM switch.  When switching to my
CentOS machine, I have about a 50% chance that any mouse movement will
cause the cursor to fly all over the screen and spew random mouse clicks
all over my desktop.  This typically causes a bunch of windows to pop
up, and it also usually causes parts of email messages to get pasted
into my shell windows.  That causes a lot of command not found messages
as well as the creation of a bunch of unwanted files because of the >
email quote character.  I can fix the mouse problem by switching to a
text vty and running a script to reset the mouse, but if I try to do
this proactively and the mouse isn't in a confused state when I run the
script, that also confuses the mouse and the only means of recovery is
to unplug the mouse and plug it back in.  The same KVM switch works
flawlessly with both FreeBSD and older Linux kernels.  Supposedly the
code that someone inserted into the Linux kernel to detect the problem
and automagically reset the mouse got yanked out, with the suggestion to
buy better KVM switches.

I also run Fedora 14 on one machine at home for MythTV.  Hardware
support is a lot quicker to show up in Fedora than it is in CentOS, but
it still isn't great.  A recent example is that I tried to expand my
storage this last weekend by adding an external enclosure containing a
couple of drives plugged into an ESATA port multiplier backplane.  I had
to plug a new ESATA HBA into one of the PCI Express slots in the
motherboard to drive it.  The first HBA I tried uses the Asmedia 1061
controller.  It's BIOS was able to communicate with the port multiplier
and find both drives, but once the Linux kernel took over, it reset
things a bunch of times, complained about not being able to clear an
error, and gave up.  Just for grins, I plugged this same card into a
FreeBSD box running 8.2-STABLE and was able to see both drives.  I also
happened have another HBA with a Marvell controller.  I tried that in
the Fedora box, but the drives never showed up.  After much head
scratching and Googling, I finally figured out that the controller was a
Marvell 9128, which didn't get Linux support until the 3.x kernel. Looks
like I'll have to upgrade to Fedora 16 for that ...

The downside to the faster hardware support in Fedora is the very rapid
turnover of its major releases.  There are new major releases per year
and each release gets EOLed when version N+2 is released, so it's
necessary to upgrade major releases way more than I'd like.  In addition
to new features and new hardware support each major release seems to
come with its own set of "surprises" as well.  The first one that bit me
with the upgrade to Fedora 14 was the overly agressive nouveau driver,
which didn't like my Nvidia graphics card and resulted in a black screen
once it grabbed the card.  Even putting rdblacklist=nouveau on the
kernel boot line didn't help.  I was finally able to get things
installed in text mode, but for normal operation I always had to rebuild
initramfs without this driver by messing around with dracut.  Definitely
not user friendly.  This finally seems to have gotten fixed (rdblacklist
getting obeyed?) with the last kernel update since I didn't have to mess
with dracut.  I also had a lot of initial stability issues with Fedora
14 and after much time digging with Google and much experimentation
(much of which didn't help or made things worse) I finally got things
working with the nohz=off highres=off boot options.  Definitely not user
friendly ...

When I get around to moving my MythTV frontend and backend to separate
machines, I'm actually thinking of switching the backend to FreeBSD so
that I can take advantage of the native ZFS support.


So how do I achieve your level of Linux computing nirvana?