*BSDThis forum is for the discussion of all BSD variants.
FreeBSD, OpenBSD, NetBSD, etc.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
This recent attitude that free software developers somehow owe someone a free windows clone which just works out of the box on every kind of hardware and if it doesn't it's dismissed as crap, is utterly bewildering.
This is not a recent attitude and it stopped bewildering me a long time back. I've been in the Linux community for more than a decade now and this has been pretty much the situation for a long time from as way back as I can remember.
I agree, complaining is useless unless you can change something. But an observation about something lacking something is not a complaint and I think it is useful as such to know what OS lacks what, both for developers and users.
I think the recent attention towards BSD has been caused by all that systemd brouhaha and a host of Linux users searching for alternatives.
Last edited by vharishankar; 03-03-2015 at 08:47 AM.
Distribution: Mainly Devuan, antiX, & Void, with Tiny Core, Fatdog, & BSD thrown in.
Posts: 5,498
Rep:
Quote:
I think the recent attention towards BSD has been caused by all that systemd brouhaha and a host of Linux users searching for alternatives.
Very true, I for one have partially gone back to BSD, partly for that reason, & partly because there is too much diversification going on in the Linux arena these days.
But there are lots of Linux people turning up on the BSD forums.
I have an "avoid wherever possible" policy towards blobs, especially towards proprietary kernel modules like the nvidia proprietary unix driver.
Agreed. If my OpenBSD developers cannot see or work with the code I don't want it on my OpenBSD box. Being proactively secure by default is a good thing.
“Has Linux lost its way?” comments prompt a Debian developer to revisit FreeBSD after 20 years
February 17th, 2015
I’ll admit it. I have a soft spot for FreeBSD. FreeBSD was the first Unix I ran, and it was somewhere around 20 years ago that I did so, before I switched to Debian. Even then, I still used some of the FreeBSD Handbook to learn Linux, because Debian didn’t have the great Reference that it does now.
Anyhow, some comments in my recent posts (“Has modern Linux lost its way?” and Reactions to that, and the value of simplicity), plus a latent desire to see how ZFS fares in FreeBSD, caused me to try it out. I installed it both in VirtualBox under Debian, and in an old 64-bit Thinkpad sitting in my basement that previously ran Debian.
The results? A mixture of amazing and disappointing. I will say that I am quite glad that both exist; there is plenty of innovation happening everywhere and neat features exist everywhere, too. But I can also come right out and say that the statement that FreeBSD doesn’t have issues like Linux does is false and misleading. In many cases, it’s running the exact same stack. In others, it’s better, but there are also others where it’s worse. Perhaps this article might dispell a bit of the FUD surrounding jessie, while also showing off some of the nice things FreeBSD does. My conclusion: Both jessie and FreeBSD 10.1 are awesome Free operating systems, but both have their warts. This article is more about FreeBSD than Debian, but it will discuss a few of Debian’s warts as well.
The experience
My initial reaction to FreeBSD was: wow, this feels so familiar. It reminds me of a commercial Unix, or maybe of Linux from a few years ago. A minimal, well-documented base system, everything pretty much in logical places in the filesystem, and solid memory management. I felt right at home. It was almost reassuring, even.
Putting together a FreeBSD box is a lot of package installing and config file editing. The FreeBSD Handbook, describing how to install X, talks about editing this or that file for this or that feature. I like being able to learn directly how things fit together by doing this.
But then you start remembering the reasons you didn’t like Linux a few years ago, or the commercial Unixes: maybe it’s that programs like apache are still not as well supported, or maybe it’s that the default vi has this tendency to corrupt the terminal periodically, or perhaps it’s that root’s default shell is csh. Or perhaps it’s that I have to do a lot of package installing and config file editing. It is not quite the learning experience it once was, either; now there are things like “paste this XML file into some obscure polkit location to make your mouse work” or something.
Overall, there are some areas where FreeBSD kills it in a way no other OS does. It is unquestionably awesome in several areas. But there are a whole bunch of areas where it’s about 80% as good as Linux, a number of areas (even polkit, dbus, and hal) where it’s using the exact same stack Linux is (so all these comments about FreeBSD being so differently put together strike me as hollow), and frankly some areas that need a lot of work and make it hard to manage systems in a secure and stable way.
The amazing
Let’s get this out there: I’ve used ZFS too much to use any OS that doesn’t support it or something like it. Right now, I’m not aware of anything like ZFS that is generally stable and doesn’t cost a fortune, so pretty much: if your Unix doesn’t do ZFS, I’m not interested. (btrfs isn’t there yet, but will be awesome when it is.) That’s why I picked FreeBSD for this, rather than NetBSD or OpenBSD.
ZFS on FreeBSD is simply awesome. They have integreated it extremely well. The installer supports root on zfs, even encrypted root on zfs (though neither is a default). top on a FreeBSD system shows a line of ZFS ARC (cache) stats right alongside everything else. The ZFS defaults for maximum cache size, readahead, etc. auto-tune themselves at boot (unless overridden) based on the amount of RAM in a system and the system type. Seriously, these folks have thought of everything and it just reeks of solid. I haven’t seen ZFS this well integrated outside the Solaris-type OSs.
I have been using ZFSOnLinux for some time now, but it is just not as mature as ZFS on FreeBSD. ZoL, for instance, still has some memory tuning issues, and is not really suggested for 32-bit machines. FreeBSD just nails it. ZFS on FreeBSD even supports TRIM, which is not available in ZoL and I think fairly unique even among OpenZFS platforms. It also supports delegated administration of the filesystem, both to users and to jails on the system, seemingly very similar to Solaris zones.
FreeBSD also supports beadm, which is like a similar tool on Solaris. This lets you basically use ZFS snapshots to make lightweight “boot environments”, so you can select which to boot into. This is useful, say, before doing upgrades.
Then there are jails. Linux has tried so hard to get this right, and fallen on its face so many times, a person just wants to take pity sometimes. We’ve had linux-vserver, openvz, lxc, and still none of them match what FreeBSD jails have done for a long time. Linux’s current jail-du-jour is LXC, though it is extremely difficult to configure in a secure way. Even its author comments that “you won’t hear any of the LXC maintainers tell you that LXC is secure” and that it pretty much requires AppArmor profiles to achieve reasonable security. These are still rather in flux, as I found out last time I tried LXC a few months ago. My confidence in LXC being as secure as, say, KVM or FreeBSD is simply very low.
FreeBSD’s jails are simple and well-documented where LXC is complex and hard to figure out. Its security is fairly transparent and easy to control and they just work well. I do think LXC is moving in the right direction and might even get there in a couple years, but I am quite skeptical that even Docker is getting the security completely right.
The simply different
People have been throwing around the word “distribution” with respect to FreeBSD, PC-BSD, etc. in recent years. There is an analogy there, but it’s not perfect. In the Linux ecosystem, there is a kernel project, a libc project, a coreutils project, a udev project, a systemd/sysvinit/whatever project, etc. You get the idea. In FreeBSD, there is a “base system” project. This one project covers the kernel and the base userland. Some of what they use in the base system is code pulled in from elsewhere but maintained in their tree (ssh), some is completely homegrown (kernel), etc. But in the end, they have a nicely-integrated base system that always gets upgraded in sync.
In the Linux world, the distribution makers are responsible for integrating the bits from everywhere into a coherent whole.
FreeBSD is something of a toolkit to build up your system. Gentoo might be an analogy in the Linux side. On the other end of the spectrum, Ubuntu is a “just install it and it works, tweak later” sort of setup. Debian straddles the middle ground, offering both approaches in many cases.
There are pros and cons to each approach. Generally, I don’t think either one is better. They are just different.
The not-quite-there
I said that there are a lot of things in FreeBSD that are about 80% of where Linux is. Let me touch on them here.
Its laptop support leaves something to be desired. I installed it on a few-years-old Thinkpad — basically the best possible platform for working suspend in a Free OS. It has worked perfectly out of the box in Debian for years. In FreeBSD, suspend only works if it’s in text mode. If X is running, the video gets corrupted and the system hangs. I have not tried to debug it further, but would also note that suspend on closed lid is not automatic in FreeBSD; the somewhat obscure instuctions tell you what policykit pkla file to edit to make suspend work in XFCE. (Incidentally, it also says what policykit file to edit to make the shutdown/restart options work).
Its storage subsystem also has some surprising misses. Its rough version of LVM, LUKS, and md-raid is called GEOM. GEOM, however, supports only RAID0, RAID1, and RAID3. It does not support RAID5 or RAID6 in software RAID configurations! Linux’s md-raid, by comparison, supports RAID0, RAID1, RAID4, RAID5, RAID6, etc. There seems to be a highly experimental RAID5 patchset floating around for many years, but it is certainly not integrated into the latest release kernel. The current documentation makes no mention of RAID5, although it seems that a dated logical volume manager supported it. In any case, RAID5 does not seem to be well-supported in software like it is in Linux.
ZFS does have its raidz1 level, which is roughly the same as RAID5. However, that requires full use of ZFS. ZFS also does not support some common operations, like adding a single disk to an existing RAID5 group (which is possible with md-raid and many other implementations.) This is a ZFS limitation on all platforms.
FreeBSD’s filesystem support is rather a miss. They once had support for Linux ext* filesystems using the actual Linux code, but ripped it out because it was in GPL and rewrote it so it had a BSD license. The resulting driver really only works with ext2 filesystems, as it doesn’t work with ext3/ext4 in many situations. Frankly I don’t see why they bothered; they now have something that is BSD-licensed but only works with a filesystem so old nobody uses it anymore. There are only two FreeBSD filesystems that are really useable: UFS2 and ZFS.
Virtualization under FreeBSD is also not all that present. Although it does support the VirtualBox Open Source Edition, this is not really a full-featured or fast enough virtualization environment for a server. Its other option is bhyve, which looks to be something of a Xen clone. bhyve, however, does not support Windows guests, and requires some hoops to even boot Linux guest installers. It will be several years at least before it reaches feature-parity with where KVM is today, I suspect.
One can run FreeBSD as a guest under a number of different virtualization systems, but their instructions for making the mouse work best under VirtualBox did not work. There may have been some X.Org reshuffle in FreeBSD that wasn’t taken into account.
The installer can be nice and fast in some situations, but one wonders a little bit about QA. I had it lock up on my twice. Turns out this is a known bug reported 2 months ago with no activity, in which the installer attempts to use a package manger that it hasn’t set up yet to install optional docs. I guess the devs aren’t installing the docs in testing.
There is nothing like Dropbox for FreeBSD. Apparently this is because FreeBSD has nothing like Linux’s inotify. The Linux Dropbox does not work in FreeBSD’s Linux mode. There are sketchy reports of people getting an OwnCloud client to work, but in something more akin to rsync rather than instant-sync mode, if they get it working at all. Some run Dropbox under wine, apparently.
The desktop environments tend to need a lot more configuration work to get them going than on Linux. There’s a lot of editing of polkit, hal, dbus, etc. config files mentioned in various places. So, not only does FreeBSD use a lot of the same components that cause confusion in Linux, it doesn’t really configure them for you as much out of the box.
FreeBSD doesn’t support as many platforms as Linux. FreeBSD has only two platforms that are fully supported: i386 and amd64. But you’ll see people refer to a list of other platforms that are “supported”, but they don’t have security support, official releases, or even built packages. They includ arm, ia64, powerpc, and sparc64.
The bad: package management
Roughly 20 years ago, this was one of the things that pulled me to Debian. Perhaps I am spolied from running the distribution that has been the gold standard for package management for so long, but I find FreeBSD’s package management — even “pkg-ng” in 10.1-RELEASE — to be lacking in a number of important ways.
To start with, FreeBSD actually has two different package management systems: one for the base system, and one for what they call the ports/packages collection (“ports” being the way to install from source, and “packages” being the way to install from binaries, but both related to the same tree.) For the base system, there is freebsd-update which can install patches and major upgrades. It also has a “cron” option to automate this. Sadly, it has no way of automatically indicating to a calling script whether a reboot is necessary.
freebsd-update really manages less than a dozen packages though. The rest are managed by pkg. And pkg, it turns out, has a number of issues.
The biggest: it can take a week to get security updates. The FreeBSD handbook explains pkg audit -F which will look at your installed packages (but NOT the ones in the base system) and alert you to packages that need to be updates, similar to a stripped-down version of Debian’s debsecan. I discovered this myself, when pkg audit -F showed a vulnerability in xorg, but pkg upgrade showed my system was up-to-date. It is not documented in the Handbook, but people on the mailing list explained it to me. There are workarounds, but they can be laborious.
If that’s not bad enough, FreeBSD has no way to automatically install security patches for things in the packages collection. Debian has several (unattended-upgrades, cron-apt, etc.) There is “pkg upgrade”, but it upgrades everything on the system, which may be quite a bit more than you want to be upgraded. So: if you want to run Apache with PHP, and want it to just always apply security patches, FreeBSD packages are not up to the job like Debian’s are.
The pkg tool doesn’t have very good error-handling. In fact, its error handling seems to be nonexistent at times. I noticed that some packages had failures during install time, but pkg ignored them and marked the package as correctly installed. I only noticed there was a problem because I happened to glance at the screen at the right moment during messages about hundreds of packages. In Debian, by contrast, if there are any failures, at the end of the run, you get a nice report of which packages failed, and an exit status to use in scripts.
It also has another issue that Debian resolved about a decade ago: package scripts displaying messages that are important for the administrator, but showing so many of them that they scroll off the screen and are never seen. I submitted a bug report for this one also.
Some of these things just make me question the design of pkg. If I can’t trust it to accurately report if the installation succeeded, or show me the important info I need to see, then to what extent can I trust it?
Then there is the question of testing of the ports/packages. It seems that, automated tests aside, basically everyone is running off the “master” branch of the ports/packages. That’s like running Debian unstable on your servers. I am distinctly uncomfortable with this notion, though it seems FreeBSD people report it mostly works well.
There are some other issues, too: FreeBSD ports make no distinction between development and runtime files like Debian’s packages do. So, just by virtue of wanting to run a graphical desktop, you get all of the static libraries, include files, build scripts, etc for XOrg installed.
For a package as concerned about licensing as FreeBSD, the packages collection does not have separate sections like Debian’s main, contrib, and non-free. It’s all in one big pot: BSD-license, GPL-license, proprietary without source license. There is /usr/local/share/licenses where you can look up a license for each package, but there is no way with FreeBSD, like there is with Debian, to say “never even show me packages that aren’t DFSG-free.” This is useful, for instance, when running in a company to make sure you never install packages that are for personal use only or something.
The bad: ABI stability
I’m used to being able to run binaries I compiled years ago on a modern system. This is generally possible in Linux, assuming you have the correct shared libraries available. In FreeBSD, this is explicitly NOT possible. After every major version upgrade, you must reinstall or recompile every binary on your system.
This is not necessarily a showstopper for me, but it is a hassle for a lot of people.
Update 2015-02-17: Some people in the comments are pointing out compat packages in the ports that may help with this situation. My comment was based on advice in the FreeBSD Handbook stating “After a major version upgrade, all installed packages and ports need to be upgraded”. I have not directly tried this, so if the Handbook is overstating the need, then this point may be in error.
Conclusions
As I said above, I found little validation to the comments that the Debian ecosystem is noticeably worse than the FreeBSD one. Debian has its warts too — particularly with keeping software up-to-date. You can see that the two projects are designed around a different passion: FreeBSD’s around the base system, and Debian’s around an integrated whole system. It would be wrong to say that either of those is always better. FreeBSD’s approach clearly produces some leading features, especially jails and ZFS integration. Yet Debian’s approach also produces some leading features in the way of package management and security maintainability beyond the small base.
My criticism of excessive complexity in the polkit/cgmanager/dbus area still stands. But to those people commenting that FreeBSD hasn’t “lost its way” like Linux has, I would point out that FreeBSD mostly uses these same components also, and FreeBSD has excessive complexity in its ports/package system and system management tools. I think it’s a draw. You pick the best for your use case. If you’re looking for a platform to run a single custom app then perhaps all of the Debian package management benefits don’t apply to you (you may not even need FreeBSD’s packages, or just a few). The FreeBSD ZFS support or jails may well appeal. If you’re looking to run a desktop environment, or a server with some application that needs a ton of PHP, Python, Perl, or C libraries, then Debian’s package management and security handling may well be attractive.
I am disappointed that Debian GNU/kFreeBSD will not be a release architecture in jessie. That project had the promise to provide a best of both worlds for those that want jails or tight ZFS integration.
I tried to listen to it as well as other in the past and I just can't get past their monotone voices. But I think both OSes are great. However I am not a fan of the whole security through obscurity thing. Just my opinion though.
Not to mention freebsd it fighting an issue with /dev/random right now which is *** can *** wreak havoc on ssh keys and their generation. With the way attackers are today, I take the road of nothing is safe anymore.
Long time lurker here, wanted to address this claim, which is at least partially erroneous.
There was (and possibly still is, I haven't checked - EDIT: checked, it was fixed on the 18th of Feb) a random number generator flaw in 11-CURRENT. 10.1-RELEASE (i.e the production release) does not suffer this flaw, so no, production FreeBSD is not "fighting an issue" with /dev/random currently. Unstable, testing FreeBSD might be, but that has absolutely no impact on present releases, and anyone running 11-CURRENT for mission critical services should really be questioning why they're in the business of system administration anyway.
Let's remember that 10.1 was only recently released, too. We still have 10.2 and 10.3 to go before the consideration of an upgrade to 11.0 is even slightly necessary (spoiler: it won't be, at least not immediately), by which point I'm sure the /dev/random problem will be fixed.
Long time lurker here, wanted to address this claim, which is at least partially erroneous.
There was (and possibly still is, I haven't checked - EDIT: checked, it was fixed on the 18th of Feb) a random number generator flaw in 11-CURRENT. 10.1-RELEASE (i.e the production release) does not suffer this flaw, so no, production FreeBSD is not "fighting an issue" with /dev/random currently. Unstable, testing FreeBSD might be, but that has absolutely no impact on present releases, and anyone running 11-CURRENT for mission critical services should really be questioning why they're in the business of system administration anyway.
Let's remember that 10.1 was only recently released, too. We still have 10.2 and 10.3 to go before the consideration of an upgrade to 11.0 is even slightly necessary (spoiler: it won't be, at least not immediately), by which point I'm sure the /dev/random problem will be fixed.
Yes you are correct and that was my fault for not being clear. It was a bug found on Feb 17 that was 4 months old in the current branch which is Freebsd's testing branch. Release as you mentioned is their production branch so I apologize for that minor mistake.
Agreed. If my OpenBSD developers cannot see or work with the code I don't want it on my OpenBSD box. Being proactively secure by default is a good thing.
It's a real pity you abandoned OpenBSD. I for one would be interested in what specific issues you encountered?
I have been up until a few days ago an avid BSD user. I have decided to come home to Slackware. All of my PCs run Slackware now. This is in no way a condemnation of the BSDs.
There're all sorts of myths and objections and "common knowledge" and "conventional wisdom" and such floating around about BSD. I'm always a little surprised at how quick some Linux people are to latch onto such over-simplifications and long-dead statements about the BSDs, especially since they then spend so much effort screaming about people doing the same thing concerning Linux. Oh well. Let's rip up a few.
Hardware
"BSD doesn't support common hardware."
Does Linux support hardware that BSD doesn't? Probably. Does it matter? Only if you have that hardware.
I'll betcha Windows supports hardware Linux doesn't. For that matter, MacOS probably supports hardware that none of the rest do. BSD supports most common hardware you'd stick in a server, most common hardware you'd stick in a workstation, most common hardware you'd stick in a desktop... There are gaps, but the gaps change from release to release, just like every other system.
Video card support, for instance, is hardly ever claimed in any BSD documentation, while Linux documentation talks about it a lot. That seems weird, until you realize that in the BSD worldview, the OS isn't supporting any of those video cards; X is, which is a separate package. So you can use any video card under BSD that you can under Linux, since neither the BSD kernel nor the Linux kernel is supporting the video card. Now, that's not strictly true, particularly in some of the more esoteric reaches of 3D and DRI, which require more direct hardware ties and more grubbing in the kernel itself. Of course, I don't follow that, so I don't even know what the current state of the world is in FreeBSD, to say nothing of Linux. Maybe BSD doesn't have support on a par with Linux on that. Maybe it does. I dunno, and it'll probably change between the time I write this and the time you read it.
But most hardware is simple. Most common IDE and SCSI mass storage controllers work just fine. Even most RAID controllers are supported to some extent. Most network cards, wired and wireless, most sound cards, some crypto-assist cards...
But it is simple. You don't care what hardware the OS supports, as long as it supports what you have. Read the hardware support lists and/or just try booting it up. You might be surprised.
When in doubt, check the lists. Hardware support lists are available per-release, such as the lists for 5.2-RELEASE and for 4.9-RELEASE of FreeBSD.
Program Availability
"But Linux has more programs than BSD!"
How do you figure? Most of these "programs" you're so hot about are things that are open source or source-available anyway. If it's written reasonably portably, 95% or better of it will compile right off on any vaguely POSIX-compliant system. Heck, just look in the ports tree; there are over 10,000 programs and packages there.
Of course, there's a lot of software out there that won't compile on anything but Linux. Sometimes, that's because it really does require facilities that only Linux has, or does things that only matter on Linux. Sometimes, that means you need to pick up a 2x4 and go find the author, because they've put in something gratuitously imcompatible through malice or laziness. There are people who do the same with BSD, or with HP/UX, of course, but the rapidly growing Linux community, combined with the number of people writing programs who have with less experience in traditional software engineering, make it far more visible there.
Of course, there are some things that won't cross-build, particularly those that stick their fingers deep in implementation details. Some require only a little work to port, some major work, and some don't even have any meaning on other systems (When did anybody ever port Microsoft Defrag to Linux, f'rinstance?) But if it's useful, it's probably either ported, or there's some equivalent or counterpart available.
And then there's stuff that isn't source-available, but distributed only in binary. Netscape's browsers, Opera, some office programs, RealPlayer, etc. Now, most of those listed have BSD versions available as well, but even so, FreeBSD in particular and (I believe) all the BSD's have a Linux emulation layer that provides binary compatibility. It won't always do the trick, especially (as above) when something's grubbing around in deep implementation-specific details. But it works surprisingly often. Linux binaries can just be picked up and run on a BSD system (at least between i386 systems, and sometimes on other architectures). More details are out of scope, but if you want more information, you can read about it in the handbook.
As a general rule: Look at the ports collection. Chances are, you'll find what you're looking for. And if not, there's probably something among those 10,000 other choices that will fit the bill.
Popularity
"But Linux is more popular."
So? Windows is even more popular. Go use that.
Usually the popularity argument really means things like "It's easier to find support", or it ties into the program-availability issue above. But there are plenty of places and people providing commercial support for BSD, and the community on the various mailing lists and newsgroups is large and knowledgeable. Just as Linux users make the argument "Who needs to pay for support? Look what we can get for free!", the same applies on this side of the fence.
Usability
"BSD is hard to use, more advanced, more complicated, less user-friendly."
Well, how can I counter that? What about it is harder? It's different from Linux, sure, but so what? In many ways, I find it a lot more logical and easy to figure out. That's where all the effort and snobbery about consistency and cleanliness pays off. Linux is a lot "different" and "harder to use" and "more advanced" and "more complicated" and "less user-friendly" than Windows, too, remember. You just think it's not because you see through that to the increased power and flexibility that comes with learning a bit about it. BSD isn't any harder, it just requires thinking a little differently.
BSD has always considered it more important to let the advanced user do more, than to let the novice do more. The theory, of course, is that novices become advanced users very quickly (a year or two), while advanced users use the system for a long time (decades). So there's probably less "fluffy" handholding frontends built into the system. On the other hand, addon packages carry their own. If KDE has some sort of user-help or tutorial or whatever built into it (I don't know, I don't use it), it'll have it on BSD too, since KDE is KDE wherever you use it. So it's rarely as much of an issue as it sounds.
Elitism
"BSD users are a bunch of elitist self-centered rude snobs."
Yup. And proud of it. :-)
You can't characterize a whole community in a phrase. There are plenty of people in the FreeBSD community who don't want to hear about your problem unless you've traced the source code yourself and found exactly where the problem is (and it better be a real problem, not stupid user error!). There are also lots of people in the FreeBSD community who'll jump out of their skins to help you on the simplest problem.
The 'RTFM'-type responses happen, of course. But they happen in the Linux community, too. Nobody's too fond of somebody asking a question that's point #4 in the FAQ which everybody's supposed to have read. The FreeBSD documentation covers a lot of topics, and in pretty thorough detail. Use it. And because the system is centrally developed, a lot of the documentation is also centrally developed and located, right there on the FreeBSD site.
Nobody wants to try and answer a question where the questioner isn't giving any useful information, either. And when you've answered the same question that's already in the docs a hundred times, and asked for the same extra information about a problem a hundred times, you tend to get rather curt about your responses the hundred and first. That doesn't make it a good thing, but every technical community deals with the same thing.
It's possible that BSD, due to its more technical and engineering background, ends up with elitism being more prevalent than in other communities. I'm not sure it really is; I think it's just more visible. One of the consequences of the more centralized development is that the end-users and the professional sysadmins and professional programmers and most of the system developers, all share the same "space". With Linux, you've got the linux-kernel mailing list, which is practically all developers. And just kernel developers and maintainers. The make and cron and locate and tar developers and maintainers have their own lists off somewhere else. There are very well segregated gathering areas like mailing lists, newsgroups, and web forums, for admins, for programmers, and for end-users.
In contrast, most FreeBSD stuff happens on either the freebsd-*@freebsd.org mailing lists, or one of a few newsgroups. That's everything from users asking questions like "How do I get ppp working?", to developers saying, "I want to add a field to device_t". And it's not uncommon for inexperienced users to use the wrong mailing list for questions. Sure, you want to gently nudge them in the right direction, but frustrations build up. And some even take, "This is a development list, you want to ask that question on questions@freebsd.org" as an "elitist" or unhelpful statement.
So, are BSD users elitist? Well, maybe. Maybe it was more prevalent years ago; reputations like that linger on long, long after their reasons for existing are history. Personally, I think the BSD elitism is just a lot more visible due to the much tighter community. Try getting a flood of people asking the linux-kernel list how to burn a CD-R or enable a feature in Apache; see how long it takes until you have "unhelpful elitism" charges coming up.
If we are talking security then it is OpenBSD all the way.
To an extent. There are some interesting projects in the OpenBSD camp with things like arc4random and pf. The thing that annoys me with them is that they have a tendency to issue patches as "reliability fixes" when they should be listed as security bugs.
012: RELIABILITY FIX: December 9, 2014 All architectures
Fix a denial of service where a malicious authority could make the resolver chase an endless series of delegations. (CVE-2014-8602)
To me, that's being a bit dishonest with your patches. It's easy to proclaim you're the most secure when you don't count certain security bugs. The "secure by default" doesn't really apply either when you start loading up services outside of the base install onto it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
