FreeBSD Myths
wiki.freebsd.org
wiki.freebsd.org
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 !
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.
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.
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.
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.
Ugh. That sounds pretty bad for an open source OS.
I wanna challenge that with my own experience. Some companies give back, others don't. I don't think it's based on license, but on company culture.
If you look at GPL and similar, what you find is that people:
- Modify for their own internal stuff, so they don't give anything back (happens with every tool)
- Modify and even publish binaries, not contributing back, acting against the license
- Modify it and release it in a way to comply with the license, but basically rendering it unusable and where it would be easier to just start from scratch
- Modify it and sometimes even release it in an obfuscated manner, sometimes with comments stripped, etc.
Now, doesn't prove you wrong. However the sentence starts with "The BSD License Means", which simply hasn't proven as true. Other examples of BSD license are: clang, Ruby, nginx, Go, node.js, OpenSSH, ...
Also this would largely apply to other licenses, such as MIT, zlib, etc. as well.
The main reason for releasing or not releasing is what the company thinks about it. Maybe they believe competition steals it, maybe they think it will lower maintenance needed for the patchset, maybe they care about broad support for their stuff, maybe they care for people finding and fixing bugs, maybe they wanna show off, etc.
Look at FreeBSD Release Notes and Commits. It's filled with companies working on it.
There is no doubt that many people don't contribute back, but from my limited personal experience the main factor is the company and I don't know a single case where it was the license deciding that.
You could also have your personal Linux patchset. If you just use it on your servers there is NOTHING forcing you to to contribute a single line back.
Without seeing the actual conversations, I'm willing to give the guy the benefit of the doubt on this.
3 months isn't too bad of a turn around time, and I'm sure the guys maintaining FreeBSD are busy, so maybe not able to reply to everybody about every little thing.
Did you bring up the attribution on the mailing list or anything? Was it just a mistake? Was it a trivial change that could have been made as part of something else?
> 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 !
Is that really something to brag about? But whatever, you get to use it that way if you want to. Still doesn't change the fact that a lot of companies do contribute back.
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.
It's also lacking a bunch of features that reached "mainstream popularity" a long time ago.
Example: ASLR, the most important exploit mitigation technique
- 2001 - PaX Linux
- 2003 - OpenBSD
- 2005 - Upstream Linux
- 2007 - Windows
- 2007 - OS X
- 2011 - iOS
- 2016 - NetBSD
Linux even has Kernel ASLR (even though its effectiveness is debatable and it's much better with the Grsecurity patchset).
I'm a FreeBSD user and run it on a number of firewalls, but FreeBSDs approach at security worries me and I consider porting everything to OpenBSD or Linux.
It did not even have signed packages until recently!
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
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.
Unix usually has users engaged at a lower level, adding a startup daemon means moving a file to a certain place. That shows that filesystems are much more the direct interface for the operating system.
Also, it is possible to have a Unix operating system, but have a completely different filesystem underneath. This is just not possible for Windows users. So there is no choice, so it is nothing Windows users think about in general.
Will it open exactly the same ? How likely is data corruption ? Will it work if I mount it on another OS or another version ? Is versioning supported ? Can it save all the modifications to a file and can I roll back to previous version if I want to ?. Can I take periodic backups without copying/transferring entire drive or entire files even ? Will using "a" file system improve/change my disk life time ?
But would you really want to work with FAT or even exFAT as your main OS? It's about 20% slower and doesn't support ACLs or journaling, so you can lose data in a crash.
So filesystems matter and Linux still doesn't have a standard choice that's as good as other OSes had 5 years ago.
Sparse files are one example. They weren't in the original NTFS, although I'm not sure when they were introduced. If your workflow involves lots of files that happen to be mostly zeroes (which is surprisingly common), then you can save a lot of space and time by simply not writing those zeroes to disk. You could achieve the same result by compressing the files, but then everything you might want to use to manipulate those files has to be aware of that compression, and you've got added CPU overhead you might not want.
Copy-on-write snapshots are another. If you've taken a point-in-time backup and want to update it, you can take a snapshot and just copy the changed files across. That's not the clever bit, you can obviously do that with things like rsync. The clever bit is that you can make both the snapshot and the new version fully working file trees, which any of your other tools will work transparently with, and still take advantage of the space saving of the shared, unchanged parts. Again, you could mimic this by either fully copying the file tree first (in which case no space saving, and extra time to duplicate the files) or with hardlinks (which rsync does, but especially on Windows not all tools work well with).
I think one of the reasons Unix users seem to be more interested in filesystems than Windows users is that it's far, far harder to develop a new filesystem (or new filesystem features) on Windows than elsewhere. The Linux kernel interface was specifically designed to make it easy to plug new filesystem implementations in, so people have. On Windows, you're pretty much reliant on MS doing it for you, so you might not even notice when significant new NTFS features go in which would be headline news in other ecosystems. NTFS doesn't have to compete, and its users are in a sense locked in.
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.
There's a bit of a difference when it comes to running servers with thousands of users where you want to squeeze every drop of performance out of your hardware and without ever losing data, as to developing an end-user POS interface or other GUI applications. FreeBSD might be picked more often for back-end applications and Windows more for user-facing applications. It's the difference between keeping one user happy versus keeping many as happy as possible.
It probably doesn't matter much what kind of car you drive in the city centre – the requirements and limits are very different than on a race track where every little detail matters in the performance equation.
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).
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".
Setting up a server should be as secure and fast as possible with no work, you should get backups, and you shouldn't need a C compiler installed, let alone /usr/src. But the docs still act like you need to be checking out the whole OS and recompiling it for every machine, and then recompile again for jails. And once you get traffic to your web server there's a few pages of sysctl numbers to increase because it won't autotune anything.
On the power user topics, is there a way to get a changelog of port/pkg updates or OS beta releases? It's hard to know when you should bother testing something.
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
Also I actually think it's a community thing. What is way stronger in the BSD community is people not being missionaries and wanting to aggregate users as much as you see it in the Linux or MacOS world (not saying that's bad!!!).
If you join the BSD community and are like "Why would I use BSD" people will often will be like "Why bother, unless you wanna learn something new? If you don't have a reason for using it, we won't convince you". This is pretty unique to the BSD community.
That also means that you are expected to not as dumb questions.
I was active in both BSD and Linux communities, and even in the more "know your stuff" communities (Arch and Linux for example) asking dumb questions wasn't frowned upon.
Yeah, you may call this elitism. Maybe it is. I don't think so, because there is no "I am too good for answering this" and in general less politics, but then it of course you can't completely deny it, if you are supposed to adhere to the typical "How to ask good questions" guide.
And really, it's not that one is better. It certainly isn't. It's a different approach. It more likes me think of how I once watched the Standford Programming Introduction Class and the guy talked about how there is different courses and some are more about being nice and holding your hand at all time and the the other is more pushing.
It's a culture thing and just like companies are successful with different cultures you can't say one is better for everyone.
Also it depends on what you count your success on. And that can be so many things, having something stable, having great bleeding edge, having a large community, a smart community, having a few big success stories or having everyone use it.
One can maybe compare it to a business plan or describing target audiences. Nobody will say that the target audience is wrong. (even though that's more the case when your goal is to make money)
And, yes, Windows users, taken as a whole, do average out to be (very) low quality users. Linux users are somewhere in between. I'm not making a argument about causation, merely one of correlation and probably something about the mean level of knowledge.
Since I run a number of systems, each of the 3 OS (FBSD, Linux, Windows) is represented. Two OS attributes define important differences, ease of administration, and ease of user applications (including installation of app software).
Here's my theory:
As I see it the OS sort out in opposite directions based on these attributes. For ease of admin I rank them as: FBSD > Linux > Windows. Ease of use/apps is the reverse order: Windows > Linux > FBSD.
From an admin point of view, FBSD is the most straightforward to configure and maintain. Windows is an admin nightmare. Linux is more complex than FBSD partly because of its heterogeneous origin and more frequent, less predictable changes.
No doubt non-tech savvy users are more comfortable and feel more productive with Windows and don't have to learn much about the OS itself. FBSD can be used as a desktop/laptop OS but that's much more difficult to accomplish. Linux has more options/apps vs. FBSD, but fewer than Windows.
These factors favor FBSD in the role of server and Windows for general users. Linux can be a server or desktop. The reason Linux is more often used in the server role is probably an outcome of FBSD's relative obscurity, not inherent Linux superiority.
When it comes to servers, given a choice, in a Linux-dominated world relatively few will select FBSD. When there's a chance to get familiar with both, the lower admin burden of FBSD makes it an attractive option.
In my view FBSD, especially in the server niche, is simpler and easier to master which encourages admins to learn it in depth, therefore its users tend to more consistently appear to have a higher knowledge level.
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.
See also Freshports: http://www.freshports.org
$ make -C /usr/ports search key=foo
# portsnap fetch extract
$ whereis foo
pkg search -g '*' | less
"pkg" has become a very useful, reliable tool.
I tried to install FreeBSD 10.3 on a new Skylake laptop. Resume doesn't work, so I asked on the forum. The answer? A stupid joke and nothing more. Are all FreeBSD users like this?
In Debian/Ubuntu/Mint style Linux it's enough to use
apt-get update
apt-get upgrade
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)?
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.
pkg update
pkg upgrade
pkg upgrade
You also have stuff like autoremove, clean, which (for checking which package owns a file), etc.
See the commands section for pkg: https://www.freebsd.org/cgi/man.cgi?query=pkg#COMMANDS
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.
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'.
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.)
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.
The barrier to entry for most UNIX-related tools is quite high for "non technical" users. I don't think that's a controversial thought. And one can hardly deny that some UNIX users like that i.e. if you can't read the MAN pages and figure it out, then perhaps UNIX isn't for you.
I think it's worse there's no sandboxing. Ports just runs all kinds of code downloaded off the internet as root. Latest version does have the very beginnings of some in Capsicum but it's not like OS X where every daemon is syscall and FS sandboxed.
> 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".
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.
There's a difference in tone there.
How is PC-BSD doing nowadays? Is it really worth installing and using?
Anecdotally, I installed it on a spare laptop last month and the first main hurdle was that the disk partitioner kept failing until I first manually fdisked the disk to a single partition.
The second hurdle was that when it booted to the desktop there was no system tray icon to enable wireless networking and select an SSID, despite the 4965 chipset being fully supported. Presumably it requires some messing-around with wpa_supplicant.
I haven't had time to go back to it but both would be deal-breakers for the 'common person'.
But don't fear. People of both projects share a lot, just try different approaches. :)
https://www.dragonflybsd.org/ (also, if you think the website isn't the nicest I agree)
Myth?
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.