While I currently have NetBSD installed, I often find myself reading alot about OpenBSD and I often see a lot interesting OpenBSD setups on Reddit etc.

I understand that OpenBSD was originally forked from NetBSD and while i'm happy with NetBSD, but I feel like I'm having a bit of FOMO... is the grass greener on the other side?

Can anyone with a bit more experience than me put a simple comparison together for me to understand why OpenBSD is seemingly more popular (clearly not the case on this forum however) ... or am I just imagining things?

    pfr i would say try both OpenBSD and NetBSD and pick one that suits your need 🙂 i previously used OpenBSD and ran vps on OpenBSD 5.5. but currently NetBSD user for my needs.

    “Only the paranoid survive.”

    ― Harold Finch
    NetBSD VPS , NetBSD , OS108

    pfr why OpenBSD is seemingly more popular

    Why do most posts on r/unixporn are of Arch withi3 with a anime girl wallpaper?

    Preferences
    If you really need to know follow @Jay 's suggestion and explore both. If you are a bit like me and, are happy with what you run, why bother?
    I've never been a "distrohopper", just looked for something I liked.
    Started with Mint and found it too bloated, moved over to Peppermint and got enough of systemd. Had a go with Porteus and in the meantime got tired of DE's in general. Three years ago installed Void with awesomewm running with musl libC and was home. I still use it although, it made me curious about NetBSD and here I am. Except for the above, I've only touched Bodhi, as my 8 year old uses it as her OS, and have been wanting to take Alpine or Adélie for a spin 😉
    Choices...

      why OpenBSD is seemingly more popular

      Security theatre

      i love openbsd and netbsd, but i would never use openbsd in anything resembling production environment.. i use it on my main machine, i love its simplicity, but the speed and reliability are nowhere near netbsd

      OpenBSD is an outstanding OS, well-documented, simple, consistent and tightly integrated, with good defaults (no need to adjust much on a default installation before having a working system for everyday use). While I partially agree with Nia, one has to give credit where credit is due, and OpenBSD, throughout all its history as a R&D UNIX with a focus on code correctness, cryptography and security, deserves praise for the many good ideas they came up with (OpenSSH, PF, CARP, W^X....).

      OpenBSD has invested a lot of energy in desktop support and tends to just work (often including graphics -with the exception of nvidia-, ACPI, touchpads). The OS comes with a really nice set of native software allowing one to easily deploy simple and secure servers. It actively supports several CPU architectures (less than NetBSD), and some happen to be very well maintained, especially SPARC64, with a nice deamon to manage LDOMs, and macPPC.
      Generally speaking, OpenBSD is regarded as an optimal choice for small to medium size appliances directly facing the internet and is particularly suited for firewalls, routers, DNS, DHCP, VPN/Tor, Web, mail servers.

      On the other hand, their attitude and philosophy (their pride) make them always want to advertise each and every feature or component of their OS, as well as any commit merged into mainstream adding even the most negligible feature. Just have a look at their official innovations page. There's a undoubtedly lot of remarkable efforts mentioned there, but also a lot of entries which do not appear as much 'important' . NetBSD or Linux could host similar 'innovations' pages (and the list would be long); the question is, however, what purpose would such an effort serve?

      NetBSD devs maintain a patched monolithic X version in base (as well as a modular one inside the pkgsrc tree), and yet they didn't renamed it with a flashy nick seemingly coming from a Infocom fiction^[1]
      Instead OpenBSD devs imported and patched Xorg (for a rootless default setup, to enhance privilege separation), then imported and patched XDM by removing XDMCP, and decided to name the former hack Xenocara and the latter Xenodm. Hope you've never come across a OpenBSD fanatic, not seldom clearly clueless about the OS design and internals (naturally, and fortunately, most of the fanboyism has nothing to do with developers; it largely comes from young KISS UNIX zealots migrating from Linux), bragging about the many features of Xenocara, 'a stripped down Xorg fork with many indispensable security improvements, devoid of all the cluttered nonsense, because X is flawed and broken...., blah, blah'.

      I'm probably speaking too much and need to be quicker now. What I wanted to stress is that much of that incredible popularity you seem to refer to is at least in part built upon a series of fandom-driven half truths and misconceptions, as well as a very good amount of official advertising campaigns, fueling the hype.

      OpenBSD overall feels like a big boring monolithic piece of software. Default installation and default settings are strongly recommended and devs tend not to like exotic configurations. All of their software appears built with the same philosophy in mind. Software should be installed via binary packages, no much left to say. At time feels like a OS built by developers for themselves, kindly shared for others to use (but if you dare ask a question, it's mostly RTFM). They're not interested in your feedback, if you want something to change you'd better come on the mailing lists with a PR ready to be reviewed, at least.
      Whatever is left orphaned without somebody eager to take up full-time maintainership, is quickly deprecated and it doesn't take much for it to be removed. Linux compat and bluetooth met such a fate. OpenBSD has no multilib, so no wine and their hypervisor (vmm) is still very limited both in its capabilities (IIRC each VM cannot use more than a core at a time) and in supported clients. The only FS available is FFSv1/2, which provides no journaling (though it has soft updates), no snapshots and no TRIM support.

      NIH is also one of their problems. One thing I miss on OpenBSD is tmpfs (no, mfs is not a valid replacementt). Julio Merino created NetBSD's tmpfs long ago, and their implementation was quickly imported in FreeBSD. tmpfs was later ported to OpenBSD too, but left unmaintained after a while and eventually removed.

      To sum up, not much to discover, not much space left to hack around, not many cool and obscure features to explore. That's the main reason which I don't like OpenBSD for (performance aside, since the difference in my experience is not so significant on desktop and can be overcome, unless you run a high-end workstation and have some heavy workload to undergo or performance requirements to meet).

      In this regard NetBSD is quite the opposite, pure freedom. Among Linuces, I love Slackware because it shares with it this same approach: "here's your fresh UNIX framework, do what the hell you want with it".
      And then there's pkgsrc. I would have never discovered NetBSD hadn't it been for pkgsrc; it represents for me alone a good reason to stay already. There are many things I find brilliant and extremely useful about that packaging system, but I really need to go now, so perhaps we can discuss it another time.

      ^[1] I remember, from the good times when I was still following BSDtalk, that Matthieu Herrb stated he had discovered that word while looking into Latin names of fish species; he liked it and decided to borrow it. Truthfully speaking, as one who studied ancient Greek, I can tell that name is of Greek derivation for sure and means something like 'foreign face'.

        I've been using Linux since 1995. At some point, I had an opportunity to install Linux on most machines at work... And I discovered the systemd nightmare. I was lucky to find Devuan at the moment to get myself out of that mess, but since then, I've been actively looking for alternatives. It seems that in 2020, the only dependable Linux distro is Void. That's a bit scary!
        Last year, I decided to explore the BSD family. The most accessible to me was FreeBSD and I learned a lot with it. However, in spite of all its qualities, there are 2 aspects that made me continue my exploration: FreeBSD package dependencies are a terrible mess (and nobody cares because of jails); and FreeBSD seems to attract more and more of the kind of people that make me feel a stranger in the Linux world.
        When NetBSD 9 was released, I decided to give it a try but couldn't succeed in installing a desktop environment due to repository problems. I only succeeded very recently, a couple of weeks ago. In the meantime, I have also tested OpenBSD 6.6 more seriously than last year.
        There are good things in OpenBSD but they are totally eclipsed by the attitude of the community. It is obvious that OpenBSD is developed by a gang of old friends for their sole pleasure and that they despise the rest of the universe. I have had my content of such people in the Linux world (e.g. Gnome, Debian...), stop! Moreover, OpenBSD is terribly slow, I don't see any valid reason to use it over anything else.
        The reason why I'm motivated to spend more time and efforts on NetBSD now is that I feel a better fit with the values and culture of its community.
        Because in the end, the most important criterion when choosing an open source OS is the people it makes you meet. If it was not for this, why bother? Computers come with Windows or MacOS preinstalled, nobody needs an open source OS for practical or technical reasons. The only true reason why we do need an open source OS is the philosophy and values it carries. 🙂

          Off-topic but,...

          20-100 It seems that in 2020, the only dependable Linux distro is Void. That's a bit scary!

          ...although, I do run Void myself, I think Alpine is also an option 😉

          EDIT: Unless, of course, if you need GlibC.

          • Jay likes this.

          This thread made me doubt a bit about my already sparse knowledge of OpenBSD security, mostly based on the official OpenBSD innovations page, their man pages, the widely shared and accepted beliefs within the BSD community, and a couple of researches I made last year in order to understand the rational and the design concepts behind PaX Team's patches and papers, which were directly implemented later on in many of the OpenBSD's exploit mitigations (as well as HBSD's - it's thanks to Shawn Webb that I discovered PaX - and NetBSD's too actually, kudos to those guys), or at least strongly influenced them.

          I wanted to see some less biased perspective (possibly by somebody not coming from the BSD land); I found this site providing quite an in-depth overview of OpenBSD's mitigations, giving credit when it's deserved and backing up criticism with consistent data. It may not be devoid of an anti-OpenBSD attitude (it comes up at times), possibly emphasizing some negligible inconsistencies, but at least, it's the first different voice with a solid enough background I've come across in a very long time.

          EDIT: reviewed also this comment for the many typos I tend to make and ignore upon first sight

          • Jay likes this.

          OpenBSD only claims "only 2 remote exploits in the base install in a heck of a long time." This is certainly remarkable, but the base install of any OS is totally useless. The purpose of an OS is to allow the execution of applications and here, every OS is equal... :/

            20-100 OpenBSD only claims "only 2 remote exploits in the base install in a heck of a long time." This is certainly remarkable

            Regarding this statement, honestly I've never understood what are the inclusion criteria for a bug to qualify as 'remote exploit in the base install'. I think they're limiting the count to remotely exploitable unprivileged arbitrary code execution cases (the first hole was a integer overflow in sshd which allowed remote attackers to execute arbitrary code during challenge response authentication, limited to OpenBSD as it involved BSDAuth, not PAM; the second time a mbuf function in the KAME Ipv6 stack miscalculated the length of the buffer causing an overflow when copying it).

            To be honest, I've seen several privilege escalation and DoS vulnerabilities being discovered in OpenBSD within the last few years. I remember a couple of years ago a DoS (memory consumption) affecting their httpd(8), and around a year ago the discovery of a Xorg bug affecting systems with the X binary set setuid (and that specifically happened to be the case of Xenocara as they seemingly needed it for their rootless setup), allowing untrusted users to overwrite system files as root using the -logfile and -modulepath parameters of the X command (they had to disable X login via startx for a while and enforce the use of Xenodm).

            If you look at the global CVE count for OpenBSD, the list is quite long, even though many are minor/locally exploitable bugs with a low CVSS score.

            More recently Qualys disclosed several privilege escalation bugs, publishing a series of briefs, one of which covered more than one; they also discovered a bug in OpenSMTPD's smtp_mailaddr() function (responsible of validating sender/recipient's domain name by accepting MAIL_FROM and RCPT TO commands), allowing an attacker connecting with a malformed address to send malicious code with root privileges to the shell that executes the MDA. There must be a reason why this doesn't qualify as a third whole in a heck of long time, but I really fail in getting it at the moment. Something clearly doesn't add up here but it falls beyond the range of my limited understanding.

            @nia , sorry to bother, care to jump back into this conversation and shed some light upon us mortal beings? 😃

            EDIT: as I side note I want to stress the fact that as code is written by other mortal beings, it's perfectly understandable for the fallacious human brain (even that of the greatest genious) to overlook on a mistake once every heck of a long time, so actually having more than 2 holes disclosed in 20+ years of OS history is actually a good thing, since it means the code doesn't rely on security by obscurity and gained wide enough attention to be reviewed outside of the its own development team. cc. @Jay

              neb this is rad, thanks for sharing! Another extremely cool initiative, which I suppose you're aware of already, is OpenBSD Amsterdam. If I ever happened to get tired of self-hosting, that's certainly the one I'd opt for.

              To further elaborate on this point, actually all the BSDs base systems come bounded with a nice set of home-grown software (with a minor contribution of 3rd party components, namely the toolchain), which is more than enough to launch simple yet fully-fledged servers (firewall, NAT gateway, BGP, FTP, DNS, HTTP, mail, file server, network file system, VMs, jails..), with the not negligible benefit of running a trusted secure system which has been extensively reviewed, tested, audited.
              OpenBSD is the one with the most featured userland in this regard and the most varied set of native network daemons

                JuvenalUrbino The "remote holes" claim isn't much more than marketing and it's not a useful measurement. As you've identified it's intentionally narrow and vague (no configuration changes, no additional services enabled, no packages installed, full remote code execution? You're not going to run an ISP with that).

                OpenSMTPD and the hypervisor have been sources of recent public embarrassment for them (when you make fanciful security claims it usually results in unwanted attention)... I'm old enough to remember Theo's "x86 virtualization is always bad and a security risk" take, a couple of years before they decided hypervisors were Good, Actually, when they're OpenBSD hypervisors.

                I trust anything that implements anything vaguely PaX-like to run sketchy code more than anything that doesn't, but I'm not convinced that with OpenBSD you get anything more than a false sense of safety over any of the other options.

                JuvenalUrbino yes, I was aware of Amsterdam - recently checked it out more closely recently as I'm interesting in "doing some serving" at some point.
                BTW he uses -current in the ISP 😎

                4 months later

                JuvenalUrbino Linux compat and bluetooth met such a fate.

                Having tried OpenBSD 6.7 and 5.9 (the latter just to try the compat layer) I can tell you you're not missing much. I also tried the compat layer in FreeBSD, which I'm pretty sure is based on similar code due to how you use it.

                This thread is interesting for me, as I'm coming from the other side as the OP: I use OpenBSD and wonder if NetBSD is worth a try. I'm happy with a minimal OS, so I'm unlikely to switch to something with more features than I really need, but I tried FreeBSD first and I've mostly written it off for now. Though I did get farther with the FreeBSD compat layer.

                Now for my experience with Linux compat: Originally tried it on FreeBSD, got PyPy running (that was my main goal, since the native PyPy on FreeBSD is deprecated, perhaps until the upstream devs figure out how to bootstrap compilation) but getting simple Linux apps to run in X was a matter of library issues. I got each dep copied over one at at time, until it complained about glibc. So FreeBSD, I only got working with command line apps.

                When I enabled compat in OpenBSD 5.9, the last OpenBSD to feature the layer, it wanted me to install something in /emul/linux that I was unable to find (few mirrors feature the 5.9 tree that I could find). I guessed that the /compat/linux tree in FreeBSD (these are Linux ELFs, not BSD binaries) might correspond to /emul/linux (which didn't even exist, except in documentation) on OpenBSD, so I made an archive of it, copied it to OpenBSD and unzipped it to /emul/linux.

                At this point I could tell that the compat layer was working, because instead of complaining about the wrong syntax (in a binary) it would complain about a missing lib instead. I would copy the lib, then it would complain about a different dependency. And so on, but unlike with FreeBSD I never got a single Linux binary application to actually run. What they removed wasn't much. As for Bluetooth... I don't use it in GNU/Linux so I don't need it in BSD, but I can imagine a number of people with hardware that is useless without it.

                • neb likes this.

                NetBSD has a welcoming community gathered around eye-candy forum on UnitedBSD.