OpenBSD 7.0
openbsd.org
openbsd.org
FreeBSD, OpenBSD or NetBSD – _that_ is the question.
Wait, maybe DragonFly actually? illumos? ...wait, I mean OpenIndiana, I think... wait, what's OmniOS? Is Darwin a thing, like I could just have BSD and macOS for free or something?
If you want something you can use as a border router/firewall, OpenBSD.
If you want something for more general-purpose computing (like a desktop or home server), FreeBSD.
If you want something you can install on your toaster, NetBSD.
Similarly, on desktop, OpenBSD can be pretty nice if you're a developer comfortable in the terminal; it runs the same graphics drivers as FreeBSD and Linux (other than NVIDIA). It's defaults tend to be a bit more sensible on desktop/laptops too IMO as its developers are more likely to dogfood it. There's been good progress on NetBSD desktops over the past few years as well, but I'm less familiar with it, so I can't comment too much.
With regards to portability, NetBSD supports more systems, but often I've found that OpenBSD is a little bit more stable on the ones they do support as they insist on not using cross compilation: so every system they do support is at least stable enough to build itself, which is a good stress test, especially on older machines.
I guess I don’t see a major difference in the complexity of that decision process in the Linux space, which might have been alluded to.
If you compare something like Debian, Alpine, and NixOS, then maybe..
The BSDs all have a common ancestor. The Linux’s tend to all have a GNU user space, the kernels are mostly the same, but the OS layout tends to differ in important ways.
Can you run FreeBSD binaries under OpenBSD? No.
edit: and oddly if you only go with this definition, that is Windows with WSL also a Linux OS? I'm guessing most people wouldn't say yes...
I would presume Linux OS to run Linux kernel on host OS. By default Windows runs Windows kernel.
They have too much disparity in terms of configuration to consider them the same OS for management purposes which is my main focusat work. But I can understand if someone with another perspective feels differently.
OpenIndiana: file server (ZFS)
OpenBSD: firewall, router, network services (DHCP, DNS, NAT)
DragonflyBSD: game server
FreeBSD: other general application services
I haven't found a personal use case for NetBSD yet, though I would like to (it is great for embedded systems).
OpenBSD might not be the best choice for any given use, but it's so remarkably consistent and understandable that I think everyone interested in alternative OSes should try it out at least once.
used it as a webserver and VPN appliance for a couple of years now.
only thing in terms of maintenance is the following when a new release is released.
pkg_add -u ( i usually update extra packages every 6 months, which is mainly lets encrypt). syspatch sysupgrade
reboot:
after reboot
sysmerge to see if i need to do a config diff.
Has been rocksolid and very future rich in base aswell.
Always read the upgrade guide before upgrading.
This release only includes changes related to SNMP, which I imagine are irrelevant to most people, though probably exciting for a subset of OpenBSD users. https://www.openbsd.org/faq/upgrade70.html
The upgrade guide for 6.9 gives a better flavor for how OpenBSD handles and documents subsystem and configuration changes: https://www.openbsd.org/faq/upgrade69.html
Notice how succinct and consistent (across decades!) are the upgrade guides. The above have the same basic format and content as this one from 2004: https://www.openbsd.org/faq/upgrade35.html I've been doing remote upgrades of OpenBSD and Linux (mostly Debian, but also occasionally Red Hat derivatives) for over 20 years. While I've fortunately only rarely encountered significant problems with any of them, OpenBSD upgrades are the only ones where I can have any confidence in understanding and tracking how the system evolves across upgrades. Follow the upgrade guide and delete outdated files (much easier since sysclean(8)), and a 10-year-old OpenBSD box can have a filesystem as pristine as a freshly installed system.
I'm not one of those people who wants pristine for the sake of pristine. But pristine is important when you care about security, and maintenance burden is a huge component of security, as are simplicity and transparency.
To me, it seems worthwhile to have fewer 0-day bugs to worry about, and more reliable separation between user accounts (fewer privilege escalation bugs, etc etc). (I also recommend setting default umask to 0077 for the same reason, except while using pkg_add -- I have a wrapper script that undoes it temporarily for that due to issues encountered.)
There are reasons people use Windows or Apple (perceived convenience), and reasons not to (long-term cost/benefit decisions for known uses).
In case it becomes useful to anyone: One way to traverse the docs is (occasionally helpful) is using something like http://man.bsd.lv/ for OBSD docs, like putting in an "=" (w/o quotes) in the search field then clicking "apropos" shows all the commands -- a useful way to learn "what is available in the base system"; or doing full-text searches (can be learned locally, I have an awkward script for it if needed),
(Edit: s/what is available/what is available in the base system/ .)
And: I find the ~"only 2 remote holes in the default install since about 1996" to be very impressive.
Edit: Another way to look at it might be by priorities. I have come to see priorities of some systems roughly as:
OpenBSD: security, openness, correctness (including of documentation), portability.
Linux: features, performance, openness, breadth of everything, compatibility, convenience (distributions vary in specifics of course; debian and/or devuan continue to impress me in their own way).
FreeBSD: performance, stability, openness.
NetBSD: portability, stability?, maybe enjoyment for its developers, openness. (I know least here.)
Windows / Apple: profitability while targeting preferences of specific groups who want different specific kinds of convenience, it seems.
For what it's worth, I think OpenBSD is intuitive because of its consistency. It's certainly been more intuitive to me than any other OS; it just makes sense as a whole in a way that no other OS quite does, and that's refreshing in a world where users are expected not to understand what their tools are and how they work.
OpenBSD just builds its intuitive bits on things you may not yet know. Fortunately, it has excellent documentation to get you started.
On OpenBSD, if you're stuck on something in ksh, cwm, pf or any other built in tool, the man page is right there. Easily accessible, easy to read and comprehensive. When I play around on my OpenBSD box, the man pages is often my first choice over a search engine.
Also, not confuse man pages on OpenBSD with Linux man pages. Those two are remarkably different. Many Linux tools have good and comprehensive man pages. On OpenBSD everything has great man pages.
Luckily, the manpages are available on your favorite search engine!
Unfortunately search engines are unreliable, some "search engine optimized" virus pages could be first, and not some bank or docs website.
To me OpenBSD is similar to what Slackware was, as simple as it possibly can be, with the advantage of a BSD being coherent and consistent.
I'm a long time Linux user and only used OpenBSD recently. I often find myself Googling Linux configs. I did use Google for OpenBSD to get started but found after a day I wasn't and relying on the man pages instead for system settings etc. They really are short, concise and complete, everyone says this but until you use them it's hard to understand.
I use Emacs I don't know Emacs. Emacs is a completely different beast to OpenBSD. Emacs is a huge rabbit hole and you spend as much time building your own Emacs as you do using Emacs. OpenBSD i've set up once which was simple as someone never using it before, and then forgot about it. It's been sat ticking away in a corner, no interruptions.
As much as I really like OpenBSD I don't think I can use it as a primary desktop. There's a few compromises on hardware support, no docker for my day job and I've read the desktop experience is slower than Linux just because it hasn't had the money and people Linux has had with drivers etc.
I'd really recommend anyone try OpenBSD for it's simplicity and educational purposes. If you use it as your main OS you will likely be dissapointed with some of the limitations, as a server / secondary educational device you might be pleasantly surprised.
But if you are looking for more focused projects, then Dragonfly for best out of box desktop experience, openbsd for security and firewall, and netbsd for compatibility and portability across loads of devices.
These are the folks that brought you the word 'hackathon', and OpenSSH. (Ever use ssh? Thank OpenBSD.)
These are the folks that actually bother to read not just a PR, but actual full codebases, just to make sure their pointers don't dangle.
It's been years since the DevOps space was first told to prefer 'livestock' -- disposable, nearly-identical instances -- to pets -- long-lived customized instances and servers -- but as every farmer knows, if you have lots of sheep, the job is a lot easier if you have a sheepdog. Not quite a pet, but not cattle, either.
OpenBSD is my sheepdog. It keeps my git repos, it runs my wireguard VPN, and it, above all the other systems I touch, is trusted.
But trust is ultimately about people, not about systems. Systems get their trusthworthiness from their creators, the way the moon gets light from the sun.
And in trustworthiness, the OpenBSD community has a breathtaking superpower: They can say no. They are good at saying no. Do you know how hard that is -- to have someone ask for a feature, and just tell them off? That's the hardest thing any manager ever has to do, and these guys are good at it. Rare, in FOSS space.
These are the folks that are so good at saying 'no' that they ship with a literal actual bespoke copy of 'vi', that does exactly what it is supposed to, does not take packages, and also does not have a package manager pulling in raw github HEADs. (I love you, neovim, but you are so trusting!)
OpenBSD has been around for most of my 20+ career in this industry and it's sort of always been this aggressively reliable paperweight of a distro. I'm never quite sure what to do with it (NixOS is my go-to for my workstations -- NixOS + Wayland + Sway + Alacritty + Neovim is as close to godliness as a user interface can come) but OpenBSD finds its uses, and in those uses, it is smooth and heavy and reliable, making it the perfect foil for the rest of my infra: For where NixOS is neurotic and brittle, OpenBSD is saturnine and malleable.
I think of my infra as sort of being like a knife blade, with a glittering Nixos/Wayland/Neovim edge supported by a soft, heavy core of OpenBSD.
If everything else breaks, so long as I have my OpenBSD instances, I can recover.
One final word: At my end, I just finished upgrading my instance at openbsd.amsterdam; big shoutout to that amazing team for their incredible support. (Mischa, in particular, is a force of nature, and I am fan. ;D)
Cheers, happy donations to the BSD Foundation!
However when I ran OpenBSD on an old Chromebook I did really enjoy using it, I made a point of trying to use just the base system and aside from needing a web browser it was extremely usable. The documentation is universally good all the built in tools are well maintained. In the near future I’m gonna setup a separate firewall/router machine from my NixOS box and I think I’m going to use OpenBSD there too.
Here's what helps me decide: I simulate a disaster. Since I'm just me, I do it on paper (empirical ways are best but are also the most expensive, and in a pinch, a thought experiment can illuminate as well. Not always the same things, but light is light.)
Try it -- open a scratch.txt and write about things that would happen, and then the things that would probably happen as a result of that.
The one that often comes up for NixOS is "I lose network connectivity." While NixOS is phenomenal in its ability to roll changes back, the fact that I need a stable Internet connection in order to make any change whatsoever to the current config makes that little piece of CAT-8 a SPOF for any number of unexpected (and intuitively unrelated) matters, making the overall system hard to reason about.
You can mitigate this by hosting your own NixOS channels, which is sort of the equivalent of hosting your own apt-get repo.
But, as you might expect, that's actually a fair amount of extra work. So I don't, especially not on laptops, where space can (still) be limited.
So, every time I do `home-manager switch` I need a viable network connection.
This is especially galling if you (like me) manage most of your apps with Nix' `home-manager`. Think it through; Nix manages (say) your word processor; you want to change the font size in your word processor; you edit your home.nix and hit `home-manager switch`.
But look at what this entails! My apartment building's fibre-optic cabling should never be a depenency on altering the font size in my word processor, but here I am. Ironically, for the sake of convenience.
Now, none of this is to slag on NixOS. As I mentioned above, it's my favourite way to encounter reality. I'm typing this to you on NixOS right now. For me, the pros outweigh the cons. Provided, of course, I have something less brittle than NixOS to back me up, and for me, that means OpenBSD.
I have an OpenBSD instance in the cloud and a break-glass procedure for getting into it. It backs up via another old-school friend, tarsnap. It hosts the git repos that contain my nixos and home-manager configs. If I can talk to it, I can simply zap my NixOS config onto some new edge device and be back up and running in no time.
I also typically have a NUC running OpenBSD present as well, in case that apartment-building fibre gets troublesome (again,) but not at the moment, because my beloved PCEngines device has apparently become unstable under any OS. But when I get that OBSD NUC set (back) up, it will absolutely have a NixOS channel on it, and it will serve as a firewall, a SAN, serving NixOS channels to the edge devices. It will have an actual serial port and a password on a wax-sealed bit of paper in my fireproof safe. Because I think ahead, and that's what I need to get back up and running under the worst circumstances.
I simply can't imagine a non-hardware-failure disaster that could take out an aggressively boring OpenBSD bastion instance. They are just relentless in their persistence.
As I keep saying, NixOS and OpenBSD pair together like honey and mustard. Contrastive but unexpectedly delicious.
Take-home: If you're building infra, try adding some OpenBSD to the mix. It can make the unrecoverable recoverable.
FreeBSD for servers and NAS, desktop. FreeBSD has high performance all around, ZFS, jails, bhyve, linux compatability, etc. But it's not as nice to administer as OpenBSD. I want to love it, but it's tedious.
NetBSD is an OK choice for anything, and very capable, but doesn't stand out for anything other than portability. If you enjoy hacking on things, you might find a lot of use in it.
I would personally never use it for a laptop.
And plenty of other OSes have FDE and everything in-between.
Not to imply I don’t like OpenBSD, I love their first class support of old architectures.
I ran OpenBSD on a Thinkpad T450 for over a year, but recently switched to OpenSUSE Tumbleweed, not because of lack of speed, but some missing applications and blutooth support.
Given I don't run a heavy desktop environment, rather just StumpWM, but still I did not in any way feel OpenBSD was slower than Linux, using the same applications.
OpenSUSE is the most solid Linux I have used so far, but OpenBSD was more to my liking setting up and maintaining. It is well thought out, simple, and... just makes sense.
Indeed but I ran it on my Thinkpad and it was a sluggish mess.
Only if you carefully pick your laptop hardware. I tried giving OpenBSD a spin as a daily driver on my XPS13 9343 and was plagued by issues:
1.) The network firmware is not included in the base OS. I had to download the firmware onto a USB storage device since the XPS doesn't have an ethernet port.
2.) 802.11ac isn't supported on my network card
3.) The login manager and window environment are unusable on a 4k screen. Trying to scale using xrandr --scale caused everything to appear fuzzy. I scoured the @misc mailing archives and could not find a suitable way to scale display without causing blur.
4.) Suspend/resume is broken and causes the kernel to panic.
5.) X.org doesn't use the inteldrm driver by default which causes choppy media playback
6.) OpenBSD puts memory limits on processes by default which causes memory hungry applications -- like web browsers -- to run choppy unless you change the memory limits.
None of these issues came up when using Ubuntu on my XPS 13. On Ubuntu it "just worked".
They're all good. I wouldn't over-complicate it. Just look at the one with known strengths that most match what you most value and dip in. A lot of the knowledge crosses over if you want to try other ones anyway, they're all related.
But if you want to try out something else, clap your hand and start installing, why?
What does this refer to in this context?
If you install everything from sources directly, or directly from upstream vendors, you may get inconsistencies, but if you install everything from your Linux distribution, you should get reasonable consistency, just as if you install everything from your BSD distribution.
ps: another instance, albeit not a BSD strength either, would be data format, every output is different, I, like a few people too wanted some json as pivot representation to cut the thousands of papercuts, that kind of uniformity is what I expect from "system"
ps --libxo json
and get json output, or xml/htmlNB: Not on OpenBSD.
My only sort of complaint in regards to FreeBSD is actually ZFS. Not that it's not fantastic, or that it shouldn't be there. ZFS does however clearly comes from Solaris, and there have been no effort to make the ZFS command line tools feel more BSD like.
Changing the tooling around ZFS probably isn't a great idea, but coherency has clearly taken a backseat to features in this case.
There's a modest amount of precedent for this kind of thing.
0: lvcreate(1M) from HP-UX 11i https://nixdoc.net/man-pages/HP-UX/man1/lvcreate.1m.html
Right, because ZFS is a foreign piece of software that runs on other operating systems. At that point you are better off keeping those tools coherent with other ZFS implementations. This is a good compromise.
I'm less familiar with OpenBSD but it is similar in terms of prioritising being a cohesive operating system and docs. Some design choices the team have made for reasons such as security make the system feel sluggish by modern standards, even compared to other BSDs. You might get a lot of mileage out of it if you enjoy old school C programming and reading the source code for coreutils libraries.
This is one of the areas where OpenBSD really shines. Their documentation is really good. FreeBSD is also quite good, but I've been consistently impressed with OpenBSD's docs since 2.5.
Linux distros can't reach the same level of quality due to being less cohesive at the base, though they do make up for it with quantity. You can search for most Linux issues and find an answer.
This speaks to the need for non-coders taking part in open-source projects.
Unfortunately, we don't live in an ideal world, so I rarely get to spin up OpenBSD outside of that due to a number of reasons like a lack of filesystems for interoperability (USB media) and firmware drivers (got to be specific in the hardware you buy for it).
1. ZFS -- by far and away the best filesystem there is. (A hella partisan take but try it out and you'll likely fall in love like the rest of us did)
2. The handbook. The handbook is gold. It's up there with some of the best documentation available.
3. Less fragmentation. The BSDs have 3 main derivatives: NetBSD, OpenBSD, and FreeBSD. (There are others but these are the main)
4. If you like LXD then you'll love Jails.
5. The BSD license. (If being the most free means something to you. I kind of like it but maybe this isn't a selling point.)
6. Can be rolling or used in an LTS fashion. It's rather easy to track -current all the time or just stick with a stable release and do periodic binary package updates.
One area to consider as a happy Debian desktop user is using OpenBSD as a router OS. PC Engines (I have no affiliation to them) makes a very nice router called "Alix" and OpenBSD works well on it. Previously, people were installing it on Soekris routers before they went out of business.
OpenBSD's firewall pf is by far my favorite, and it and OpenBSD have a lot of nice networking features and tools to tinker with. It's free of blobs (in the default install), free of known bugs (in the default install--but generally your router will work well with only the default install), and configured to be reasonably secure by default. The documentation is also frequently praised.
How many other modern, full-fledged, well-maintained and open code OSes run in 32 Mb of RAM?
Once you figure out how to set it up then the audio just works. That is a killer feature compared to the situation I had to deal with when I was doing Debian on the desktop.
For me the coolest thing about OpenBSD is it’s the simplest OS that is still of practical use (i.e., not counting ones that are purely for research or education). So if you’re curious about how any part of the system works, it’s easy to just dive into /usr/src and figure it out. It’s also entirely configured via simple text files rather than some opaque systemd monstrosity.
https://wiki.archlinux.org/title/systemd-networkd#network_fi...
But simple i would not call it...compared to bsd ;)
I tried finding similarly named files, to no avail. Knowing the notorious ADHD of the systemd developership, I wouldn't be surprised if this file is moved, renamed, and uses a different format every six months.
http://manpages.ubuntu.com/manpages/focal/man5/systemd.netwo...
or
find / -name '*.network'
But yeah, BSD's would have them at one place -> /etc ...linux-distro standardization is a terrible mess.
EG Debian's systemd fork puts it in /lib/systemd/network/ (and lots of other network files in /usr/lib/systemd/network/).
The vast majority of users control wpa_supplicant indirectly through NetworkManager, so it's not widely known that it can be configured using simple text files. But it can! On Arch linux, the default config file location (for network card wlan0) is: /etc/wpa_supplicant/wpa_supplicant-wlan0.conf.
iwd is similarly straightforward to configure using text files. Using the CLI front-end is typically a nicer experience, since you get to pick the SSID from scan results and you get quick feedback if you mess up the password. But if you want to do it manually, just create one file per wifi network (containing SSID, password, etc) in /var/lib/iwd/.
/etc/apt/apt.conf.d/
BSDs are very tightly integrated. The entire OS is very consistent and 'correct', down to the tiny and pedantic details like putting things under /usr that are usually installed in /bin, because that's the way it's supposed to be. (Ex. `/usr/local/bin/bash`)
Think of it like reading Wikipedia, no matter which page you read it seems like it was written by the same person. That's the kind of consistency that OpenBSD intends to create.
The base shell, ksh, is at /bin/ksh.
You probably know that but I just felt like being pedantic this morning :).
The MirBSD Korn Shell also descended from pdksh, and it can be found here:
http://www.mirbsd.org/mksh.htm
I don't know about the feature differences and code quality between these two; they both implement most of ksh88, and a small amount of ksh93.
I prefer mksh when I need something more than a POSIX shell.
It's an interesting idea, and while I feel bash is absolutely 'good enough' to be part of the base system, I wouldn't want zsh or fish part of my base system - so it's then a matter of opinion whose shell is bloat and whose is essential. So I respect their decision to not include bash in the base image - it's meant to be uncompromisingly lean and simple.
$ ls -l /bin/bash /bin/dash /bin/mksh
-rwxr-xr-x. 1 root root 964536 Nov 22 2019 /bin/bash
-rwxr-xr-x. 1 root root 113536 Nov 5 2018 /bin/dash
-rwxr-xr-x. 1 root root 296192 Jan 27 2018 /bin/mksh
The Debian Almquist shell has nearly nothing beyond POSIX (I believe that local function variables are the only extension). This is the Ubuntu system shell, and it tolerates no bashisms. Alternate POSIX shell implementations in OCaml (and somewhat ADA) accuse Almquist of not using formal grammars and imply that dash is not a safe implementation.https://www.irif.fr/_media/rencontres/pps2018/regis-gianas.p...
I would say that mksh implements 80% of bash functionality in much less space, and closely follows ksh88; mksh is also licensed such that Android uses it as /bin/sh.
Apple has switched from bash to zsh. I don't know the motivations for this, but preferences for shells wax and wane. BSD doesn't include bash (in base) more because of license than code quality.
POSIX seems to be all that we can agree on, but I do wish that standard could grow; it's stuck in the '70s.
GPLv3 vs BSD or MIT license. I lived zsh anyway, switched some of my BSD shells to it afterwards.
I don't like the fact that you have no way to clear the history buffer if you've accidentally dropped a password at the prompt. Bash has history -c. I don't have shared history enabled, you could unset that and it'll stop segregating.
Anyway, zsh is a lot more versatile and familiar than tcsh for instance, so it's almost always my go to shell on FreeBSD as /bin/sh is quite limited, but also miles ahead of the Debian shell regarding features.
Don't get me wrong, I was a BSD user for many years (FreeBSD 3.5-5.0) but I don't think that's enough reason to switch.
If it doesn't sound compelling to you, that's okay too, Linux is great. But I do think focusing on the consistency of design really is the best high-level summary of the difference between Linux and OpenBSD.
Am I actually wrong about that? Is there some declarative configuration system I should be using, which I've simply never heard of?
In the BSD context, consistancy is that human effort has been put in to get the userspace to look similar. Similar behavior of command line tools, similar documentation, similar configuration, etc.
It looks like you're talking about consistancy of packages across installs, which is a totally different issue.
I’d be really interested in seeing a variant on top of openbsd that has a comparable declarative layer. If anyone knows of such projects, please share!
I wouldn't be entirely surprised if OpenBSD works too, I might spin up a VM and see...
[0] https://github.com/NixOS/nix/issues/3280
I am still running ubuntu on laptop and will switch when the next install is a thing, but I am running freebsd on server for years now and while i tremble on each update for the laptop, I dont for freebsd, even when updating from 12.x to 13.x.
Based on years of experience on both operating systems. I was surprised only once when freebsd made change where the base network settings weren't by default copied into fibs (you wont encounter this... probably ever) and even then I needed an hour to figure what the change was.
On the other side, I no longer count the nasty surprises the linux distributions played on me (like /etc/resolv.conf being overwritten by systemd resolv, just as trivial change). My laptop is unbootable for a year as they messed something regarding the order of zpool import (bpool being imported before rpool - probably a race condition) so i have to import it manually or it doesnt boot, while I have freebsd zfs root for ~10 years and it never failed me.
Details like that made me insecure about linux. And on the other side, made me highly secure about freebsd.
I think that (again, this is subjective, speaking only for myself)...
I... trust... BSD... guys. Based on experience.
I... dont trust linux... distributions. Based on experience.
But it might just be me.
Not sure the teething process has finished there, but I share the sentiment.
What bothers me that the old way is still there (/etc/resolv.conf) while it is being generated by systemd. I can accept the change where the dns information is stored. Fine, it is no longer the same file, I dont care. While on the other side, if I get parallel mechanism, that is keeping the old, this is really an annoyance. That is hard to identify.
The ZFS has nothing to do with systemd and I havent even touched stuff like jails/lxc, byhve/kvm, memory consumption, quality of code,... as I have said it, it is subjective and it is about trust into operating system. Linux distributions dont have it. They blew it just too many times. BSD didnt.
It is hard to be objective there, just try the BSD. And please do report your findings.
If you want to use it as a daily driver, you're probably going to run into some headaches. That being said, if you're willing to put in some time, learn a little bit and forgo some software here and there, you certainly *could* use OpenBSD as a daily driver. One really cool thing about OpenBSD is that the OpenBSD devs use the OS as their daily driver.
You'll likely keep hearing about how good the OpenBSD man pages are. I always thought this was a weird thing to mention and make a big deal about. But holy crap, the OpenBSD documentation is amazing. Reading it has definitely made my own documentation at work significantly better.
The downside? There are a couple. The biggest two are that, 1) you're not going to find a lot of the software you might normally use; and 2) The performance is not great and battery life is not very good.
This all depends on the hardware you bring to the table. A random Acer laptop with a questionable ACPI table is probably going to have problems, but a previous-gen Thinkpad X1 should be great because that's what the devs use.
> you're not going to find a lot of the software you might normally use
This really depends on your use cases – I can do most of the development I want on my OpenBSD laptop. But there are some gaps, absolutely.
> The performance is not great and battery life is not very good.
Harder to argue this one. It's getting better release by release, though :)
...and I love it! Documentation is generally excellent, readable, and centralized. There are only a dozen or two processes running on a fresh system without much of anything installed, and idle CPU usage is the zeroyist zero I've ever seen for a server OS. The directory structure in `man hier` is actually used, and it feels like the surface area of what I have to learn to be proficient is sooooooooooo much smaller. It's not perfect (home and end keys don't work consistently) but definitely a breath of fresh air.
Plus, many programs (ezjail, for example) integrate tightly with ZFS, which is also awesome. I know linux finally got quality ZFS support but BSD (along with solaris) are OG
Plus, now I am learning a great deal about how MacOS is built.
Funny enough, I have a DJ controller (Pioneer XDJ-XZ) that uses BSD for its operating system. So it seems to be a great embedded audio OS as well!
If you want to use it on the desktop, you can use it for basic surfing or 90s video games. I’m using it for fun mainly. There is no jails / docker / virtualbox so I don’t use it for coding.
OpenBSD isn’t really a desktop OS, desktop users typically use FreeBSD because there are many more packages. FreeBSD is a completely different OS.
Why? You have PPSSPP, Dolphin, maybe some current-gen emulators, and lots of sourc ports. And fnaify for Mono games.
With recent versions of chrome/firefox and 3d acceleration on amd/intel graphics, you're not limited to "basic surfing".
The only reason I can think of that you would say that is that perhaps you do e.g. have an NVIDIA card (why...) and thus you're stuck with no accelerated graphics.
(Having said that, my needs might be atypical.)
Edit/ps: last I knew, it had something like 10_000 binary packages available, in addition to the base system.
Are you a software engineer or CS student? If so, I'd say that OpenBSD really shines in code simplicity, clarity, and consistency. This is also a matter of taste. What drew me in initially was the quality and consistency of the kernel source code, consistent high standards in documentation, and the design of system interfaces and libraries.
I like being able to answer my own questions and I find that easier in OpenBSD than in Linux. Sometimes I sit for hours and simply flip back and forth between documentation and code exploring how things work. I feel that this level of consistency and availability of information within the system feed creative urges on my part.
I like to write code and I feel like I have an easier time doing that in OpenBSD than Linux (again, a matter of tastes.) This is in large part because my workflow tends to happen at the terminal.
I would be surprised to find that VSCode, Slack, Discord, and other electron-y applications can be made to work in OpenBSD at all... maybe they do, but I've never felt the need to try, so if they don't I'm fine with that.
I think OpenBSD is well adapted to a specific kind of user and a specific kind of problems. If you're paranoid, or a developer, or just like the terminal window, or prefer design consistency over broad compatibility and feature variety, you might find that you really enjoy using OpenBSD.
By all means, give it a spin if for no other reason than to learn about a thing that's out there that a bunch of people enjoy.
If OpenBSD is not for you, that's okay too. I don't think that the user base, developers, or community have ever been looking run campaigns aimed at growing the popularity of the system. For me that's a good thing, the developers seem less prone to chasing the next thing that will expand their share in a market, and are more focused on making a thing they want to use - which translates well for me. YMMV.
https://www.openbsd.org/goals.html
But if your video is Nvidia, you are out of luck until they open their drivers.
>Be as politics-free as possible; solutions should be decided on the basis of technical merit.
Someone has the wisdom to put this in nearly 20 years ago.
I was naive in thinking it was always about the focus on priorities, as in Security vs NetBSD's portability. So I decided to read up on it [1]. Since Wiki seems to be purposely quiet / unclear on the incident.
Turns out Open Source Politics isn't that much different 25 years later.
I've been using Vmware PhotonOS for Docker host VMs, and I'm pretty happy with it.
For everything else though... I'm thinking Ubuntu, but I'm not sure. Might a *BSD be a good option? Does it have any real advantages over Linux? Or any drawbacks for that matter?
I don't want to run CentOS Stream.
But if it makes you uncomfortable there's always Rocky or Alma Linux.
My focus would be database. Microsoft's binary ODBC libraries and Oracle Instant Client are Linux binaries. FreeTDS and Oracle SQLcl/JDBC are options on a BSD, but there are drawbacks, as there likely would be with any binary packages.
I know that both RedHat and Oracle will migrate an installed CentOS to their platforms (RedHat does it more violently, by replacing every installed package). Alma & Rocky might also be migration options.
1) For VM Desktop Usage on a laptop 2) Server only.
I can’t believe this is free. Glad I support the BSDs with the pittance every month that I can but wow amazing work.
https://www.openbsd.org/lyrics.html#70
But hey, if the Artwork is the release point for you, that's fine with me ;)
> The current release is OpenBSD 6.9, released May 1, 2021.
But no release for you, until homepage is.
https://man.openbsd.org/timeout.1
But it's not something I'd miss - unless it's used in some scripts I'm unaware of..
(Wouldn't it be nice if the most secure OS was (re)written in the safest language available today?)
So yeah, I doubt rust is ever coming to OpenBSD. I'm also skeptical about the level of adoption rust will see in the Linux kernel. People are usually resistant to change (sometimes for good reasons).
https://lobste.rs/s/jx3cr6/initware_systemd_fork_runs_on_ope...
And to be pedantic (this is an OpenBSD thread, after all), it's not "systemd", it's a fork of systemd called "InitWare", and the GitHub repo describes it as "alpha software".
Someone also pointed out in the discussion you linked that it doesn't seem to include journald. Here's a relevant PR: https://github.com/InitWare/InitWare/pull/27
* https://www.bsdcan.org/2016/schedule/attachments/337_bsdcan-...
Yeah NO.
OpenBSD is the opposite of backward compatibility by design.
You should have known that before installing at your customers site en masse.
That's probably one point why PFsense is based on freebsd and OPNsense on hardenedbsd.
>>They should take a page out of Microsoft's book here.
or mine?
>You should have known that before installing at your customers site en masse.
Sorry for stating a fact that you should know your OS before sprinkle it all over your customers.
I wish these kind of caveats were highlighted more often, not only when it comes to OpenBSD but also when it comes to anything regarding Linux. Instead, you have people defending why the way how OpenBSD works is the "right" way.
I'm honestly somewhat surpised at seeing how much people are attached and married to their tools.
Last time I gave a look at OpenBSD I immediately noticed a huge courtain of gatekeeping around pretty much anything.
Meh.
Uhm... well, I've been using it since 3.0 (when pf was introduced) and its been very stable. You have at least 6 months to convert your pf and its never taken me more than a day to get it changed. Its well documented and frankly, even with all the horror stories, I've found friendly help each time I had a question (do read the manual before asking a question). Looking at your firewall rules every 6 months isn't exactly stressful.