OpenBSD is a bit like Jazz music. When someone asked Louis Armstrong, "What is jazz?" his reply was, "If ya gots to ask, ya'll never know."

Though it will most definitely seem elitist, there's some subtle wisdom there; You need to experience it for yourself to learn the what's and why's. Similar is true for all of the BSD's. If you're just looking for a fast bullet point list and "executive overview" (a.k.a. "buzzword bingo decision support"), you'll never find a reason to run any of the BSD's, and worse, you'll never learn on your own why zealots like me exist.

The thing you're missing is the experience of learning it for yourself. You might come to a different conclusion than me, and that's fine, but you would still benefit from the experience.

Unfortunately, this is all concealed by a veil of elitism (see parent). Expect many replies on how mandatory access control does not improve real security, virtualization is a flawed idea, and soft updates are superior to journaling[1].

All in all, it's more religion than science.

[1] NetBSD removed soft updates because it was, well, unmaintainable:

http://article.gmane.org/gmane.os.netbsd.announce/399 https://lwn.net/Articles/339337/

But there's got to be a way of summarizing its appeal. We are talking about an operating system, and not Kafka short stories or Haydn string quartets, after all. Otherwise I'll have to go with elitism as the most likely explanation. A common sentiment among jazz enthusiasts, by the way.

Its upgrades are rolled out like clockwork, and are always evolutionary improvements on the previous version.

I run a NetBSD box and got into kernel hacking just from reading man pages.

I suspect OpenBSD's documentation is even more comprehensive.

The very best advice I can give you is try it yourself, and keep at it for a while. It will take some time, but you'll get the chance to form your own opinions through experience. You may or may not have the required time, effort or curiosity to get into any of the BSD's, and that's perfectly fine if you're perfectly content with what you're running. On the other hand, you might wonder why HN is running on a BSD (FreeBSD). Maybe PG and RTM know something?

  > On the other hand, you might wonder why HN is running
  > on a BSD (FreeBSD). Maybe PG and RTM know something?

Moreover, they're using FreeBSD. I kind of understand why someone would prefer BSD over Linux -- we're talking about OpenBSD, though, and specifically about OpenBSD whose adherents rarely articulate why their chosen system is superior. That's all I wanted to know.

ghshephard, thanks for the reply.

* Secure and functional out of the box. The base install comes with many common services ready to go, and I don't have to worry if I turn them on.

* Simple, understandable. With a little learning, I understand how my systems will behave. I love it that the man pages are present, current and thorough.

Are there downsides? Yes, of course there are. Hardware support is often lagging, and some OS features are still missing that have been in other OSs for years. OpenBSD is a smallish project, and a few dozen part-time devs can only do so much.

So do I recommend that everyone use OpenBSD for everything? No. But I think it's worth learning and adding to your list of options. There are roles where OpenBSD is simply the best choice available, and roles where it's either poor or plain unworkable. To discount it for anything because it isn't best for everything is a limiting viewpoint.

Lastly, anecdotal... of the people I know who are really actually familiar with many OSs (Windows, Mac, various Linux, various BSD), all of them like and use OpenBSD to some extent. These are people who know their options and will choose what they need to get the job done well.

those are both really vague. what doesn't work and what is missing that anyone really cares about?

Hardware support: mostly cards from various vendors who won't release open specs. Like Adaptec, nVidia, et al. For Linux you get vendor blob drivers or quote open source unquote drivers written under NDA in which the actual functionality is obscured. Or various things on laptops don't work, or whatever. These limitations are not much problem for me, but they bother some people. If I build a server I spec it out with compatible hardware. No big deal.

For many applications none of the above matters, or matters a lot less than the benefits gained. I like OpenBSD and use it for servers and workstations. OpenBSD has pros and cons, like any OS. For my usage, the pros are a long list and the cons don't matter much. But if I were tasked with building a processing farm with tons of cores and memory to run a massively threaded crunching program then I'd pick something else. But I'd still keep the farm walled off behind OpenBSD.

Also, have used it on desktops for clients. But only POS ones.

Most Linux distributions I've played with (CentOS, Redhat, Ubuntu Server, Debian) are pretty mediocre when it comes to security. I've actually stopped using Debian since this incident :

http://www.debian.org/security/2008/dsa-1571

In addition, my own experience would point out that OpenBSD is more reliable than Linux, but I'm just a single data point.

For development however, we use FreeBSD for a wide range of reasons including ports freshness.

http://www.awe.com/mark/blog/20101130.html

And as much as people dislike SELinux, it does help a lot in confining applications. OpenBSD does not provide comparable techniques.

OpenBSD always goes with simple, easy to understand solutions that "just work out of the box" and can be easily configured and maintained. They build those simple solutions into the OS, they do not (and will not) bolt on complexity.

Yes, we hear this every time. But this is the same project that advocated systrace, which provided access control with respect to syscalls. I do not see much of a difference between systrace and a mandatory access control framework, except that the implementation of systrace was flawed, it didn't support file labels, and SELinux has a more sophisticated policy language.

The OpenBSD Project has a very narrow view of security, and do little to improve attack mitigation for software that is not in the base system (ports).