Your browser doesn't seem to support CSS, which this page uses for all styling. Don't be surprised if it looks kinda boring.

[Jump to nav]


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.


"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.


"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.


"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.


"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-* 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" 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.

Are we there yet?

Well, that's a lot of stuff said. Let's try to wrap it up.

  1. Intro
  2. Dramatis Personae
  3. Design :: The Base System
  4. Design :: The Ports Tree
  5. Technical :: Releases
  6. Technical :: Upgrading
  7. Technical :: Ports
  8. Philosophy
  9. Myths
  10. Conclusion
  11. Responses