
FreeBSD Myths - type0
https://wiki.freebsd.org/Myths
======
alacombe
> FreeBSD Has a Closed Development Model

Given that it took me 3 month to have Jack Vogel (then maintainer of the
driver) acknowledge there was an uninitialized variable bug in the e1000(4)
driver, leading to countless user frustration, despite detailed technical
analysis and patch. Let me openly challenge this assertion... The issue ended
up being fixed (or actually, buried in a huge patch) without attribution [ed.
of course!].

My kind regards, but from experience, Linux folks is more open than BSD folks.
YMMV.

> The BSD License Means Companies Don't Contribute Back They don't !

I've worked for 5 years in a [small] company using FreeBSD as the main
development platform, heavily hacking the TCP and network stack. We leached
plenty, and didn't contribute a single line back !

~~~
drewg123
Let's just say that the Intel drivers have a pretty checkered history and your
experience was not unique. There are new people at Intel working on their
drivers, and they are more responsive. Also, iflib is coming, and it will move
a lot of the stack-facing driver code from the Intel (and other) drivers to a
common location. It is much higher performance and far less buggy than the
vendor code it replaces.

The beauty of the BSD license is that you don't have to contribute back if you
don't want to. Some companies contribute at lot. For example, the Netflix
contribution of async sendfile, CAM support for NVME, etc.

~~~
alacombe
My experience is not limited to the e1000(4) driver. The device tree driver
subsystem is based on hardware model from the early 90s, the mbuf API is
plagued with code duplication. Nobody want to touch this because the old guard
is pretty much locking these interface. Everybody praise the Lord PHK, but his
actual code in the tree is really sub-standard... The way to change things is
to do what Adrian Chadd has been doing, sneaking in, and changing stuff
behind's people back.

The way to contribute to BSD is easy, you have to be big to have enough
influence (including monetary wise) to get stuff in. When you are a small
nobody, you end up being treated as such.

Comparatively, I've had Linus look up at some issue I used to have with Linux
USB stack (which were likely local interconnect issue). A world of difference.

edit: while I think about it, most _large_ changes in FreeBSD are discussed in
private. Public discussion on patch and technical discussion is frowned upon.
At the end of the day, the dev submit at 10kloc patch that is unrewiewable,
and it gets in with rather poor amount of discussion. The only public
discussion held is pretty much bikeshedding. There is _way_ more interesting
technical conversation happening in a day on the LKML than will happen in a
year on FreeBSD ml.

~~~
drewg123
The problem with mbufs is that they have been around and been extended since
the 80s. And Rototilling the interface will break a LOT of hardware. One of
the nice things about iflib is that abstracts mbufs away from drivers. Of
course that doesn't help much with crusty old drivers, but it does help some.

Having worked on both systems, there are some things I like better about mbufs
as compared to skbs. But BSD badly needs the skb frags (eg, attached pages)
concept to avoid excessive pointer chasing. We've been using an internal (not
shared) patch that puts attached pages into an iovec, but it needs a lot of
cleanup before upstreaming.

Oddly, I've had just the opposite experience as you. I've always found
contributing to FreeBSD much easier. I was the author of network drivers for
an IHV (not Intel) at a previous job. FreeBSD was a million times easier to
deal with than Linux. I had a commit bit, and just developed my driver in
head. Whereas with Linux, submitting even minor patches was a major ordeal
thanks to davem and the netdev cabal. The Linux driver was often lacking
features as compared to FreeBSD just because getting patches in was so time
consuming.

There is actually quite a bit of public discussion of patches in Phabricator
these days.

~~~
alacombe
then maybe hardware vendors should contribute their code so that API could be
changed all along, instead of keeping it paywalled. Though, I doubt they want
people to look at how poor quality they are.

And yes, my job was also to "integrate" custom drivers for our appliances
bells and whistles (eg. fail-to-wire interfaces, hardware sensors, etc.), in
our source tree.

------
adamnemecek
If you haven't read the book "Design and implementation of the FreeBSD
operating system" ([https://www.amazon.com/Design-Implementation-FreeBSD-
Operati...](https://www.amazon.com/Design-Implementation-FreeBSD-Operating-
System/dp/0321968972/)) you should. It's possibly the best "applied" OS book.
It also contains some interesting code samples in the book which is
surprisingly uncommon in comparable books.

FreeBSD has for years had some features that are only now reaching
'mainstream' popularity (e.g. jails, which containers are based on). This
books explains all that in quite a bit of detail and manages to stay high
level enough not to get boring with the details but gives you enough detail to
have a pretty detailed understanding.

It's also one of the few books that talks about networking in very practical
terms (and not like OSI layers and whatnot) which makes me say that it's also
possibly one of the best books on networking (you learn quite a bit about
networks from how OS's work with them).

It also has the hands down best file system around (the book also talks about
that).

And unlike large parts of linux, the kernel source is actually pretty legible.

~~~
skrebbel
As a lifelong Windows user, I've always been surprised about the obsession
Unix users seem to have with filesystems.

I mean, as an end user (developer, but I assume that doesn't matter), what I
expect from a filesystem is:

    
    
        * let me save a file in a directory
        * let me open it again
    

I also appreciate how many tools can use stats (eg filemtime) for good effect,
and how fine grained permissions help keep my computer secure. All filesystems
I've ever used let me do these things, and have for a long time.

This probably makes me a Blub programmer in file system terms. What am I
missing? Why should I be dissatisfied with NTFS? I mean, in all honesty I
don't even know which filesystems my various hard drives and sd cards have - I
just save and open files.

~~~
astrobe_
It's about how the FS does this stuff.

Take for instance the old FAT filesystem from MS-DOS. If you use it on an
SD/SSD (or even a USB key, that's more or less the same tech), you're likely
to burn it fast, unless the device does "wear-leveling" internally. Journaling
filesystems like Ext4 avoid that by make it so that they don't overwrite again
and again the same sector even if the system overwrites the same file again
and again.

Another aspect is resilience to system crashes or power outages. A sudden
power outage can leave data half-written, including the file allocation table,
which may result in severe data corruption. This is especially important for
embedded devices, but not only. Some file systems are designed with that
possibility in mind.

Then there are performance considerations. FAT had to group sectors into
clusters because of the limited number of FAT entries, so a little 1Kb file
would actually use something like 8Kb on the disk (Windows still display both
sizes BTW). There's also caching policies. If you want something "crash-
proof", you don't want any write cache. But if you want something fast, you
want a big cache. some filesystems pick resilience, others pick performance,
others let you set the parameters you want.

~~~
wolf550e
I think you have confused journaled with log structured filesystems.

~~~
astrobe_
Yes I had.

------
SwellJoe
I think the best thing about FreeBSD is the incredibly high quality of its
users; I don't know how that would fit into a "myths" page, but it's worth
knowing. Maybe in a section covering how much less popular FreeBSD is than
Linux and other operating systems. It could point at that while there are
(many) fewer users, they are, on average, extremely well-educated about their
system.

I'm nearly always impressed by the quality of bug reports we get from FreeBSD
users. They're more likely to include a patch, more likely to include specific
details about how to reproduce the problem and reasonable theories about why
the problem is happening. I don't know if this is correlation or causation (or
which direction the cause/effect goes; i.e. are FreeBSD users better educated
and that's why they choose FreeBSD, or are they better educated because they
have to be in order to survive on a more challenging platform...thus it could
be survival bias, rather than any real cause/effect) and I don't know if it is
self-reinforcing (i.e. smart users breed more smart users because they're
better able to guide new users in smart directions).

All that said, lest I begin to sound too positive about FreeBSD, I still use
Linux exclusively for my production servers and desktop/laptop. It's a great
system with great users, but the sheer inertia of the Linux ecosystem is
overwhelming. The Linux kernel alone has more contributors in _each release_
than the entirety of the 400 commit bit havers on the whole of FreeBSD.

Luckily, of course, FreeBSD gets to leverage lots of things that are mostly
driven by the Linux ecosystem (Gnome, KDE, etc. all sorts of things that are
predominantly funded by Red Hat, Canonical, SuSE, IBM, etc. for their Linux
products).

~~~
smsm42
> I think the best thing about FreeBSD is the incredibly high quality of its
> users;

I suspect survivor bias in action here. At least I would consider a
possibility that these users are so well-educated about their system because
they have no choice. And that's not always what one wants. I don't really want
to be extremely well-educated about the details of my car. I just want to
operate a couple of buttons, levers and other gadgets and get quickly and
safely from point A to point B. I couldn't care less how the car does it, for
all I care it could have magical pixies inside.

Now, I'm not saying BSD users doing it wrong. On the contrary, if it works for
them that's great, and becoming the master of your tools is both personally
rewarding and enriching. But - if you're preaching to outside audience, one
has to mention that "BSD users are very knowledgeable about the details of
their system" might also mean "you can't use this system unless you become an
expert in it, if you're just interested in being a casual consumer you're in
trouble".

~~~
qwertyuiop924
I suspect self-selection: Right now, Linux is the most popular Unix. If you're
going to another system, there's probably a reason, either technical or
ideological. But to know enough to know why you might want to move already
requires a lot of technical knowlege. And the will to actually do it, stick it
out, and learn the different ways the system works requires a certain
willingness to learn (although the excellent docs DO help).

It's not so much that you can't use the system if you're a casual consumer,
it's that if you're a casual consumer, you won't bother.

Also, it's not a bias: We're trying to root-cause why the freeBSD community is
so knowledgable. if it's because only the most knowlegable are capable of
using it, that isn't a bias, it's just a result.

/nitpick

~~~
smsm42
It's bias in a meaning that the cause is not BSD making their users somehow
knowledgeable, but only users having enough motivation and knowledge to become
power-users continue to use BSD. So if you approach it as a new user
evaluating whether to use BSD, saying "BSD users are very knowledgeable" may
mislead you as to the reason why.

------
smsm42
The problem with these lists is that they are technically correct but
misleading. E.g. yes, you can run Linux software with some plugins and Windows
software with WINE. Except not every software would run, you'd have to jump
through hoops that very well may be too high for your level of technical
expertise and worst of all, you have no idea upfront if it'll work or not.
Choosing OS is a big step, but it's also a foundational step which by itself
does nothing for you - you then need apps. And when you read this list, say
"OK, cool, all my software is Windows but I'm sure Wine will handle that" and
then discover you can't really do any work - that's be bad for you.

Same with drivers - sure, BSD supports "wide range" of hardware. However,
unless you are very skilled in hardware specs, there's no way for you to know
whether _your_ card that you just bought in the store/on amazon is in this
range. _This_ is the problem that bothers people - that _their_ card would not
be supported, not the global number of supported cards.

Same for binary packages - it's nice that it has binary packaging tools, but
how I know the software I want will be available in package form? E.g. on
Linux I can look into Redhat or Debian package repos and see what they ship,
or see download page of any major software vendor and look for "Download for
Linux" button - but while I see a lot of DEB/RPM/APT/YUM distribution
instructions, I rarely see any BSD instructions.

~~~
jlgaddis
Packages currently available for FreeBSD 10:
[http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/](http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/)

See also Freshports: [http://www.freshports.org](http://www.freshports.org)

~~~
vacri
Is there a cli tool to browse that, or do you have to go to the web?

~~~
jlgaddis
If you have the ports tree [0] installed, you can browse through /usr/ports.
There's a subdirectory in there for each port, named "category/port". You can
search the ports tree using (replace _foo_ with your search term):

    
    
      $ make -C /usr/ports search key=foo
    

You can install the ports tree by running:

    
    
      # portsnap fetch extract
    

[0]: [http://www.freshports.org](http://www.freshports.org)

~~~
bojo
An alternative with less typing:

    
    
        $ whereis foo
    

This will return the path to the relevant port if it exists.

------
frik
Can someone debunk the myth I read about the FreeBSD package management
system?

In Debian/Ubuntu/Mint style Linux it's enough to use

    
    
      apt-get update
      apt-get upgrade
    

and only the changed packages including all interdepencies are downloaded and
installed in the correct binary form (x86/x64/arm...).

How does FreeBSD really handles package management and is it ahead or behind
the current state-of-art in this respect? And what is on the roadmap to
improve the status-quo (in case there is a need)?

~~~
ivoras
That particular case - upgrading everything - is actually supported pretty
well. Of course, there's the distinction between the base system and app
packages - the base still needs to be upgraded another way (freebsd-update).

It's the much more useful case of upgrading complete subgraphs of package
dependencies that still wasn't implemented when I last looked at it a year
ago.

If you have application packages A1 and A2 installed, and a library package L
on which both of them depend on, then if you upgrade A2 to a newer version
which requires (and is linked against) a newer version of package L, pkgng
will simply not upgrade both L and A1. The pkgng devs simply declared this to
be out of scope.

For a time, pkgng (now just "pkg" as it's the only one) looked like it could
be the best thing since sliced bread, only for the devs to arrogantly dismiss
the most common dependency-related operation used in practice. It's the single
biggest issue which turned me away from FreeBSD, since I don't want to write
package manager code, don't want to maintain my own package repos, and don't
want to track "snapshots" (i.e. 6-months old "freezed" package repos, without
security updates) which are the three "workarounds" proposed to me at the
time.

This is important because FreeBSD's ports and packages are on a "rolling
release" model, i.e. often (daily/weekly, depends on the maintainer) updated
to the latest upstream version, so the lack of complete subgraph package
upgrades regularly leaves you with broken apps.

------
gallerytungsten
re: FreeBSD is Just OS X Without the Good Bits

The "good bits" are things like Photoshop, Illustrator, and Quark.

Sure, I'm aware there are alternatives like Gimp and [whatever]. But the
alternatives are kludges for edge case experts; and not for people who need to
Get Stuff Done.

PS. I operate a FreeBSD server. It's great for that.

~~~
jomamaxx
The 'good bits' of OSX is that there is no such a thing as 'drivers' from the
users perspective.

If you have to use the word 'driver' \- it's not user friendly.

If you have to 'build' anything - it's not user friendly.

99% of people want to use their apps - even most devs just want a clean,
stable, bug-free, well documented and consistent platform to develop on.

I have nothing against any of the unix flavours - all the power to them, but
I'm not sure that these kinds of articles are hitting the mark when it comes
to anything remotely resembling mass adoption.

Free BSD is not a 'product' really, I would argue that it's 'technology'.

~~~
danieldk
_The 'good bits' of OSX is that there is no such a thing as 'drivers' from the
users perspective._

Well, unless you buy some hardware that is not from Apple. Buy a 802.11ac USB
stick (because your Mac has 802.11n and you cannot upgrade the hardware) with
Mac drivers. The vendor decides to release a (buggy) driver update for El
Capitan half a year after it's released.

Pretending that the driver problem does not exist on macOS does not make it go
away.

(Mac user since 2007.)

~~~
jomamaxx
"Pretending that the driver problem does not exist on macOS does not make it
go away."

I never said there was not a driver problem.

I alluded to the user perception of drivers.

Users in this day and age should have absolutely no need to be aware of the
concept of 'drivers'.

Do you have any drivers for your Android? iPhone?

The very concept may very well be dated and perhaps there is a a better
solution in 2016.

------
parennoob
From the "FreeBSD is good for servers, not for Desktops"

> If even this is too much effort, PC-BSD is a full-featured desktop system
> built on top of FreeBSD, with an easy-to-use installer and the option of
> commercial support.

Seriously, it is this sort of "the user is so stupid if they can't compile
their own software easily" attitude that turns me off about projects like
FreeBSD. How hard is it to simply _not_ say this stuff, and gain a lot more
users into the bargain? Just say something friendly, like "If you would prefer
an OS that works out of the box, PC-BSD is also available".

~~~
LeoPanthera
I don't see that attitude in what you are reading.

Any OS which the user has to install themselves has to assume a certain amount
of knowledge in the user. It's completely fair to say "And there's an even
easier way if you prefer" as well.

~~~
dwc
Your version, "and there's an even easier way...", does sound nicer than, "If
even this is too much effort, ..."

There's a difference in tone there.

~~~
LeoPanthera
Well, perhaps, but it feels incredibly minor to me. Even if true, I don't
think the tone represents the intention.

------
tete
I use FreeBSD, but if you think FreeBSD 4.x was great (related to the
"everything after was bad" myth) and also if performance is your thing you
should take a look at DragonFly BSD. Matthew Dillon who is largely responsible
for FreeBSD works on this now.

But don't fear. People of both projects share a lot, just try different
approaches. :)

[https://www.dragonflybsd.org/](https://www.dragonflybsd.org/) (also, if you
think the website isn't the nicest I agree)

------
gosukiwi
I tried using FreeBSD for my web dev environment once. It was nice, I just
hated the fact that I didn't have Dropbox and some node packages (like node-
webkit) didn't quite work as expected.

------
Scarbutt
FreeBSD is a second class citizen when it comes to the JVM.

Myth?

~~~
grkvlt
No, very true, sadly. I wonder if the C-school hackers on BSD just look down
on Java as far too 'Enterprisey' for them? Or has this changed?

------
walrus01
Noteworthy that they say it can run as a xen domU, but not whether as PV or
HVM. HVM is a huge performance hut.

~~~
tachion
Not only it supports both PV and HVM (with PVHVM in works) but also it can run
as a dom0.

~~~
Freaky
Last time I checked PV was only supported on i386.

------
aswanson
I just want a single download freebsd distro for the desktop to play around
with. Doesn't seem to exist.

~~~
monorailz
Maybe DesktopBSD? [http://www.desktopbsd.net/](http://www.desktopbsd.net/) I
dunno, I haven't used it but others have said that it's a simple install.

I bought a Lenovo Thinkpad to run a FreeBSD laptop and don't feel that the
amount of work I had to do to get it to a useful state was all that different
from the amount of work with Fedora on my desktop computer but I've been using
both FreeBSD and various Linux distros for several years and don't know your
amount of previous experience with either FreeBSD or Linux so YMMV.

------
mp3geek
Does FreeBSD have anything to compete with V4L/DVB ?

~~~
tobik
Yes, it has V4L/DVB support via the multimedia/webcamd port/package, which is
essentially a user space port of Linux' V4L/DVB drivers.

[https://www.freshports.org/multimedia/webcamd](https://www.freshports.org/multimedia/webcamd)

------
mavhc
From 2013

~~~
wongarsu
More accurately: from 2012, with minor updates from 2013 and 2016 [1].

1:
[https://wiki.freebsd.org/action/info/Myths?action=info](https://wiki.freebsd.org/action/info/Myths?action=info)

~~~
drewg123
Indeed. There is 100G support now, for example.

~~~
nickysielicki
Bhyve not being mentioned under their virtualization section is a pretty big
hole, too.

~~~
Sanddancer
Bhyve's in the second paragraph of the virtualization section. It talks about
virtualbox, then bhyve.

~~~
nickysielicki
D'oh, don't know how I missed that.

