Somewhat related OpenBSD is the fundament of my self-hosted homelab since it runs DNS, DHCP, a firewall router and a small local web server. Configuration is a dream compared to Linux and probably even compared to FreeBSD. You just need to go through the FAQ and copy&paste the relevant examples and modify them as needed. I don't know why it's so complicated on Linux where you need to appease a handful of daemons and find your way through a labyrinth of config files. I run a separate Linux based KVM host though.
OpenBSD used to run my network but Plan 9, specifically 9front is even easier. Everything is configured using NDB which is a flat text file containing entries for each system on the network. On my CPU server I run DHCP, DNS and TFTPd, which are three lines in /cfg/$sysname/cpurc. That's it. No init system and no /etc. Just start the programs which all look at the same central database for config info. When I setup PXE booting it took literally 5 minutes of adding the tftpd line, adding an extra bootf= tuple in the machines ndb entry, a plan9.ini in /cfg/pxe and I had a machine pxe booting 9front over the network when turned on.
OpenBSD is a very well kept secret that very few people are aware of. As close to nirvana as I can manage.
The fact I miss pretty much all the drama around the latest corporate take over attempts on Linux is just icing on the cake. The toxic slug strategy is an amazing one that more open source projects should use.
I can't find the article where I read it, many years ago now, but it was about strategies that small communities can adopt to keep their culture from being subsumed by the mainstream.
One was to pick a set of norms repugnant to the mainstream that everyone currently in the community can tolerate and enforce them rigorously on all new members. This will limit the appeal of the community to people like the ones currently there and will make sure that it never grows too big.
Thus your community is as appetising to activists attempting a hostile takeover as a toxic slug is to a bird.
As an example from six years ago, when the code of conduct madness had just reached its peak:
>I believe OpenBSD's code of conduct can be summed up as "if you are the type of person who needs a code of conduct to teach to you how to human then you are not welcome here".
> >I believe OpenBSD's code of conduct can be summed up as "if you are the type of person who needs a code of conduct to teach to you how to human then you are not welcome here".
Trouble is, the people who are most likely to need a code of conduct to tell them how to behave are also the most likely ones to strongly object to one on the basis that they don’t need a CoC to tell them how to behave.
True, but what you have ignored is that jerks exist equally on all sides of any CoC.
It's just as often as not that the producers and promulgators of some CoC are the jerks. In other words CoC's don't fix anything by merely existing. A few lines in a charter or mission statement already does the same to have something to point to just for formality and documentation sake.
--
[edit to expand or re-state a little...]
It's not that there is no problem and everything is fine already. It's that CoC's are almost always a thoughtless and ineffective, even actively counter-productive response to the problem.
A coc is an attempt to make an easy solution for something that there probably IS no easy solution for.
The problem takes the form of a continual fresh stream source of problem. IE a forever stream of new jerks, and existing jerks who dodn't just do one thing today but continue to exist tomorrow and the next day.
And so the solution can only be a matching continual case-by-case counter-effort, from intelligent insightful people who have good judgement.
Yeah, that doesn't scale and isn't easy and only some people do even a half-way good job of it.
It's just not a problam that you can bash script away.
But trying to do so is an example of being just a different color of jerk making life worse for others, but just in a different way and employing different mechanisms.
It's not just that jerks exist. It's that this "we welcome anyone who doesn't need a CoC to behave" is functionally equivalent to "we welcome jerks."
It's true that you can't just throw together a CoC and declare the problem to be solved. But there is value in writing down some ground rules. The purpose is not to "script" enforcement, it's to have something concrete you can point to. Having a CoC that says "no personal attacks" won't stop personal attacks, but it will let you very quickly shut down anyone who comes back with something like, "you just need to have a thicker skin."
> I believe OpenBSD's code of conduct can be summed up as "if you are the type of person who needs a code of conduct to teach to you how to human then you are not welcome here".
I think that the goal of any code of conduct is to prevent any semblance of arbitrary and whimsical punishment, which can kill entire communities.
Linux unfortunately has to endure with toxic contributors and even maintainers, and history showed that when those maintainers fail to human and consequently the community banishes them, they go on a tirade arguing all kinds of conspiracies. A code of conduct is a form of checks and balances, and code of conduct violation processes serve as processes to collect and present objectively verifiable paper trails of exactly when snd how those maintainers failed to human, and how bad at it they were. Those types can't simply argue their way out of a list of messages they were awful to others, how exactly they violated the code of conduct, and how bad it was. Thus any stunt they pull is immediately rendered moot by the deliverables from the project.
To me this seems to be true. From what I’ve seen CoCs are overwhelmingly used as a tool to enforce and reinforce a certain kind of ideological point of view.
As a result of this typically CoCs are used to block contributions or block contributors from projects where the people enforcing the CoC they wrote wield it as a weapon against men whose perceived personal politics they disagree with. And typically rumours are enough to trigger CoC proceedings against them.
> To me this seems to be true. From what I’ve seen CoCs are overwhelmingly used as a tool to enforce and reinforce a certain kind of ideological point of view.
I don't know which codes of conduct you have been exposed to. The ones in Linux cover basic things like not being cool to attack other maintainers with posts like:
> Get your head examined. And get the fuck out of here with this shit.
> Quite ironic then that CoCs overwhelmingly lead to arbitrary and whimsical punishment.
I don't agree. I think it has been working quite well in spite of the conspiratorial bullshit excuses made up by those who failed so hard to human to the point they were slapped with one.
Nevertheless, one of the values of a code of conduct is that people like you and me can check the deliberation and hear what all interested parties had to say. Without a code of conduct, the one with the loudest voice and the more interest to subvert code of conduct deliberations could basically dedicate their life shit-talking the project.
> A code of conduct is a form of checks and balances, and code of conduct violation processes serve as processes to collect and present objectively verifiable paper trails of exactly when snd how those maintainers failed to human, and how bad at it they were.
That's the opposite goal; the CoC is to be as broad as possible while still being as vague as possible.
It's a tool that has been repeatedly weaponised against the out-group by the in-group - there is never any sense of even-handed usage of a CoC against the community.
There are levels to being a dick. I think that chronically online types tend to forget that at the other side of the screen there are real flesh-and-bone people who would find it unacceptable to be addressed in a disrespectful way.
There are a few nice to haves that would really help me out with making an open bsd transition. I thought of writing them myself because I am getting very fed up with Linux for the above reasons.
- IDE support is an issue still
- Filesystem challenging when using a laptop that runs out of battery
- MATE lacking volume and WiFi controls
- This one is just me being picky but a GUI to help me gain a better understanding of the security settings or alternatively more up to date books.
- I am not exactly sure on how to correctly use virtualization and I need it to support docker workloads at work
Your points are valid but I'd like to present counterpoints:
> IDE support is an issue still
IMO, languages and platforms that require IDEs, also leads to complex software that is hard to maintain. The only exception is smalltalk.
> Filesystem challenging when using a laptop that runs out of battery
Easily resolved by using apmd and it `-z` flag. I think there's a couple utility out there that you can script for monitoring battery level.
> MATE lacking volume and WiFi controls
One of the good strength of OpenBSD is that the cli utilities are quite nice that I've not installed gui replacements (I'm using cwm). I don't mind doing a few `doas ifconfig` every once in a while.
> but a GUI to help me gain a better understanding of the security settings
I'm with you on that one. But the man pages are truly extensive. And the OS code is fairly readable.
> how to correctly use virtualization
Current vm solution is very bare. For docker, you'll need a linux VM, but the installation process maybe troublesome. It only supports serial interaction, which can be disabled by default in some distros.
> One of the good strength of OpenBSD is that the cli utilities are quite nice that I've not installed gui replacements (I'm using cwm). I don't mind doing a few `doas ifconfig` every once in a while.
I also don't mind doing things like this for network, but for volume this is very much an instant always-there requirement. If I need to mute/lower/raise the volumne in a hurry, I don't want to hunt for the application playing the sound, then find the volume slider on it, etc.
This is literally a deal-breaker for desktop/laptop users.
What I'd like to know, if there are any OpenBSD people reading, is how hard is it to contribute a fix or similar to make the desktop environment's volume control work?
I can obviously fix it for myself with some gui script/keyboard shortcut/etc, but I'd rather have anything be in the default installation whenever I refresh the install.
“ IMO, languages and platforms that require IDEs, also leads to complex software that is hard to maintain. ”
The truth is that I (and probably other users) don’t always have the luxury of choice and a large portion of commercial codebases have a very large number of files. Sometimes, it is multiple codebases at once with a very large number of files .
“ Easily resolved by using apmd and it `-z` flag. I think there's a couple utility out there that you can script for monitoring battery level.”
Yeah but I don’t want to accidentally lose data if I shut the lid and accidentally forget to plug the thing in for a few days .
“ One of the good strength of OpenBSD is that the cli utilities are quite nice”
I don’t want to enter and exit a cli tool in order to increase and decrease the volume . Ideally it’s a control in the top right or a keyboard mapping . What if something loud begins playing in a browser tab and I have to change the volume quickly?
Hello! Here are my thoughts on your totally valid concerns of using OpenBSD on a laptop.
> IDE support is an issue still
Yes, I agree. I enjoy using VSCode for most projects and there is no native support today in 2025 as far as I know. It is possible to use the web version (vscode.dev), but naturally, this lacks some features of the desktop application.
Typically I use some lightweight editor like Leafpad which has some basic IDE features. Not a replacement for a real IDE, but just an idea.
> Filesystem challenging when using a laptop that runs out of battery
Yes, OpenBSD uses FFS2 as the default file system. It's a solid filesystem with extensive history and testing, but it's not particularly tolerant of sudden power loss. In my experience most OpenBSD systems will come back online automatically after power loss, but there is a risk it will drop into single user mode if `fsck` wants a human in the loop.
There are some things one can do to help mitigate this, granted it's not very appealing coming from a more fault tolerant journalling FS: automated backups, using the `sync` option on your main data partitions (can affect performance), and of course monitoring power as mentioned.
IMO, this is a bit easier to manage on desktop or server roles where one can put everything behind a UPS.
> MATE lacking volume and WiFi controls
I haven't used MATE on OpenBSD. It's possible it's a combination of hardware + OpenBSD + MATE if it's not working. I know I have had working media controls on OpenBSD laptops in the past but I tend to stick with older laptops, Thinkpads, etc.
There are some in-base utilities to probe media keys and hook into X etc. if you're open to scripting a bit on your own hardware.
But yeah, after using Linux on laptops, it would be annoying for media keys to not Just Work after installation.
> This one is just me being picky but a GUI to help me gain a better understanding of the security settings or alternatively more up to date books.
Fortunately, there aren't too many security settings to change on OpenBSD. The most common one for laptops would be to enable SMT, e.g. enable hyperthreading on CPUs that support it. It is disabled by default as SMT is difficult to secure properly, but it does naturally improve performance. The command is `sysctl hw.smt=1`, or `echo 'hw.smt=1' >> /etc/sysctl.conf` to make it permanent.
> I am not exactly sure on how to correctly use virtualization and I need it to support docker workloads at work
Virtualization is a little unusual on OpenBSD. It's not quite as flexible as qemu, FreeBSD jails, bhyve, KVM, etc. The `vmm` and `vmd` systems were built in-house by the OpenBSD team. It is currently limited to just one core per VM the last I checked, and only supported serial and not VGA, so no way to run Windows under it for example.
I have had great success running Alpine Linux under OpenBSD and then running Docker on top of that, which opens the door for many tools and apps to run under an OpenBSD hypervisor.
There are also some VPS providers out there that fully dogfood OpenBSD and run their entire VM architecture on OpenBSD, such as OpenBSD Amsterdam, so it is totally viable depending on what one needs to virtualize.
Of course, one can run qemu on OpenBSD and virtualize whatever the heart desires.
---
That said, while OpenBSD can be a great laptop OS, it can require a bit more setup and understanding compared to a mainstream Linux OS. IMO it's still worth playing around with, even in a VM or on different hardware (desktop, Raspberry Pi, etc.) just to see the OpenBSD way of doing things, because it is truly a wonderful OS to use and learn. Other OSs start to feel a bit clunky to me after using OpenBSD for a while. :)
You only need an IDE if you’re dealing with lots of symbols and a complicated module system (Java, .Net). That’s when you need a code indexing tool. For a lot of language, a text editor is enough.
One of the reasons you don't see a lot of books around OpenBSD (aside from the very small userbase) is that the built-in documentation is so good. The manpages are actually worth reading, and for the more complex services, include examples and additional reading.
But still, the rest of your points are very true. OpenBSD is really not for everybody, but I think that's one of its strengths. It works extremely well for the people it works for, because it's not trying to coax new users into the fold.
Also, you know, like you don't have to use OpenBSD for everything. I still have plenty of Linux servers, and Linux computers, because there are some things OpenBSD is not suited to.
My impression is that the BSD's are laser-focused on providing efficient environments for networking backbone software to exist in, so special attention is paid to making it easy to orchestrate everything with rc.conf and keeping anything not required for these goals out of the default installation; while Linux (and its distributions) being far more general-purpose naturally will take more configuration.
Linux packaging tools are bad and the people who make Linux packages generally don't do a very good job at it limited by tools and motivation.
So much linux software doesn't come with sane defaults out of the box, doesn't have an easy path to common desired configurations, and doesn't have reasonable documentation. PARTICULARLY for "open" software that has a paid hosted option.
I say this after decades of a career where a very large proportion of the frustration and "stupid work" I've had to do involved getting a piece of software to do something obvious.
Working with the BSDs is just delightful in how wanting to do something turns into something working with ease.
> I don't know why it's so complicated on Linux where you need to appease a handful of daemons and find your way through a labyrinth of config files.
Not too mention that some newer servers you might want to run are containerised and have few, if any, instructions for how to set them up without containers.
Speaking of Linux, OpenBSD’s hypervisor (vmm) supports it so I managed to get docker and containers running on my server via Alpine Linux. Opens the door on all the latest ‘modern server stuff’ running happily on an OBSD box.
Have you dealt with hardware failure or instability yet? It can be pretty annoying to pin down and isolate, unless you keep an order of magnitude of hoarded hardware around.
I run FreeBSD in my homelab, too! One reason is the stellar ZFS support, but the simple fun of doing stuff differently is definitely a thing, too. And I like FreeBSD jails.
For me, the balance between all the overhead of the "cattle, not pets" approach and the manual way is the a README.md file for basic setup, and then having Ansible stand up the rest of the configuration. The host is configured as a Jail host, then individual services live inside the jails. Creating and configuring the jails is also done through Ansible.
Overall, I really like the setup.
I can individually SSH into each jail to allow easy debugging, I can snapshot the jails, and data lives on a special ZFS subvolume that I mount into each jail at "/bucket".
This way, I can throw away the jail at any time, fire up Ansible, and have everything up and running again in no time.
If you don't know about them already, you may be interested in service jails (forthcoming[1] in 15):
> A service jail shares the complete filesystem tree directly with the host (the jail root path is /) and as such can access and modify any file on the host, and shares the same user accounts with the host. By default it has no access to the network or other resources which are restricted in jails, but they can be configured to re-use the network of the host and to remove some of the jail-restrictions.
Sounds interesting, but it sounds like that would mean installing the service software and it's dependencies into the root filesystem. I'm relatively sure I don't want that, as it would create a big mess on the host. I have stuff like Nextcloud in my jails, and wouldn't want to install PHP and all of it's deps outside the dedicated filesystem of the jail.
But it's very cool to see continued development, jails are such an awesome feature!
I've done something like this in the past, it works really well. Have you used Poudriere? I never tried it, but it sounds promising. Ansible is a good idea as well. I just wrote some shell scripts that parsed a file with some packages and hooks to set up the jails.
These days I have my FreeBSD server providing NFS for a k3s instance on a different box.
I really wanted to love FreeBSD. Growing up in grade school my friend's older brother was a contributor and I thought he was the coolest guy ever. I loved the ethos and I agreed with this post. But practically, I just ran I into too much pain.
- firewall? Lots of pain and hard to find friendly, best practice starter templates. Wherever I looked, people said "it's complicated." After a lot of tinkering and learning I finally got a setup that was pretty safe. (I think.)
- pm2 was buggy on FreeBSD because of some issue with process IDs getting lost. That was pm2's fault, not FreeBSD's. But I still wanted to simply run different processes and keep my logs somewhere. Well, I guess I could write rc.d scripts for that. But keeping logs from the processes started by rc.d scripts? That also appeared to be a world of pain, and wherever I looked for answers people said "it's complicated."
In the end, it was just too much having to re-invent the wheel for common server tasks and I had to say goodbye. It's not you FreeBSD, it's me. I'm just not an OS dev.
> - firewall? […] Wherever I looked, people said "it's complicated." After a lot of tinkering and learning I finally got a setup that was pretty safe. (I think.)
I felt this way about pf when I first got PF going around 2011 for my home router/firewall box. Not saying this is the same for you or anyone else, but my issue was that I was approaching it from the point of view of “I want to configure a home firewall router with PF” instead of “I want to learn the fundamentals of what a firewall does”.
It took me a few more years to get well-versed in all that stuff: the structure of packets, what NAT actually means (what addresses are being translated, why, and where), what's going on in the state table, how to debug when things aren't doing what I expect, etc. Once I did it became much more straightforward to express in my `pf.conf` what I want to do, but you're right that doesn't really help new users.
> Lots of pain and hard to find friendly, best practice starter templates.
For a very simple NAT gateway, one could set `firewall_type=simple` and then `firewall_simple_(iif|inet|oif|onet)(_ipv6)?` to configure the ISP-side and internal-side interface names and IPv4 and IPv6 network ranges for each.
For a very easy single-machine firewall, one could set `firewall_type=client` or `firewall_type=workstation` if you want to host anything. For the latter, `firewall_myservices` and `firewall_allowservices` control what ports are enabled and who (other networks/IPs) have access to them
> - firewall? Lots of pain and hard to find friendly, best practice starter templates. Wherever I looked, people said "it's complicated." After a lot of tinkering and learning I finally got a setup that was pretty safe. (I think.)
I don't use much FreeBSD these days, but pf (from OpenBSD, I know), is one of the best things since sliced bread.
In my first job I was working for a company selling a third-party vertical software and we were proving support for it. We were using a very expensive symantec vpn with most customers connecting with a 33.3kb phone connection, until we reached the license limits, and there was no money for new licenses. In a pinch, me and a coworker set up a new server with openvpn, freebsd, pf, and a ruby-based dns server that I don't remember anymore, and we grew an order of magnitudes more customers.
It's been more that 20 years, I still don't know how to use firewalls in linux, (there are many, I just pretend they don't exists) but I would still be able to setup a pf firewall if needed. I need to say it again, pf is a joy to use.
My gripe with FreeBSD right now is that I miss something like docker swarm. bhyve is fine but AFAIK it works only on a single host. Give me something that works on a bunch of hosts, and I will come back right away
I had similar issues with it. What helps today are LLMs. It’s really a boon to configuring such things. You do it on ace and forget unless that’s your job. Did you try to do what you had wanted back then with a recent LLM?
PF seems to me like pretty much the most well regarded firewall there is -
with a nice, sensible DSL for config. If you don't like like it, you can use use IPFW or IPFILTER, which are alternative, built-in, firewall front-ends.
- In the end, it was just too much having to re-invent the wheel for common server tasks
Maybe you have built your routine around a system that have reinvented the wheel? I think FreeBSD knowledge degrades more slowly than that of Linux distros.
- I'm just not an OS dev.
That's how I feel when I enter the chaotic Linux world. Do you think my life revolve around keeping up with this shit? :)
> That's how I feel when I enter the chaotic Linux world.
I feel that as a Linux user. I really like Linux, I use it on my desktop and it runs all my servers. Delving into forum posts to find some solution to a specific problem can be exhausting. Sometimes you get a top result from like 2011 and it is out of date so you then need to spend X minutes trying to look up something more recent.
You haven't really gone 'round the block in the world of quasi-modern Linux until you're Googling for answers and guidance to what seems like some obscure issue, wherein: The noise is intense and replete with bad answers, unanswered questions, lack of report (positive? negative? how 'bout "none"?), and dumb SEO spam.
Time passes (how much time? are the birds singing yet?) as you keep slogging through that endless sea of muck.
Finally, you run across an old post on some forum where the person not only wrote about the problem, but also the cause of the problem -- and the answer.
So you're reading along, working to once again evaluate whether your problem matches their problem. And the more you read, the more familiar it all seems... like you've been there before.
"It can't be," you say to yourself.
But you scroll back up to the top of the comment and look at the author's name anyway.
And yep, sure as anything: It was you. Six years ago, you wrote about that exact problem yourself and posted a perfectly-cromulent solution to it.
So you fix it (again), note that the birds are in fact singing, and to try to sleep for a bit while pondering your life's choices: You could have found a hobby in origami or perhaps woodworking. Maybe worked as a Mennonite tradesman producing leather goods, or as a carpenter (even an Amish one if any of that seemed too high-tech).
But you didn't. You chose this path instead. It could have all been so simple, but it isn't.
Addendum:
I've used FreeBSD as my daily driver (I hate that term) since around 2004. Including through cs/math university. With Windows in a VM for "I need it".
The longer I've used it the more I'm annoyed by the trivialities of Linux distro management. And the bugs that happens between ill fitting parts composed by underfunded distro developers.
And I didn't mean to imply that FreeBSD is stale. There is big stuff happening continuously. Right now it's compatibility with Linux Wifi drivers, which will make FreeBSD more laptop-able. And pkgbase, which brings some of the compile-your-self flexibility of FreeBSD to binary management, and merges the two tools that decides what makes up your system into one. And kinda makes FreeBSD into the slim system that people already claims it to be.
My pet conspiracy is that pkgbase happened because the powers that be didn't want the 1000 battles to remove junk. Any time anyone wants to remove something there's always one or two guys on the mailing list claiming their livelihood depends on not having to do "pkg install Ø". With pkgbase its all gone.
They might've been trying freebsd back when pf wasn't well supported. Back when I last used openbsd (which might be nearly 20yrs ago now - eek), pf support on freebsd was lagging quite a bit.
Not sure what things are like now though - I'm guessing it's much better as pf was obviously the best option :)
I spent a lot of time 25 years ago learning to love BSD in general, but FreeBSD in particular. I tried to make DragonflyBSD my desktop OS for a time. It’s sad how little love BSD gets nowadays…especially given how much of modern iOS / macOS owes BSD (for BSD subsystem that’s on top of the Mach kernel).
I use it every day as my desktop OS. Vanilla FreeBSD even, not dragonfly.
I like it because it's so stable. They don't have this Linux thing where they have to change everything around to incorporate the latest fad, and there's also not so many big tech companies constantly messing with the code. Linux has too much corporate influence for me. I don't want Huawei or Amazon to be messing with the code I run all the time. The grassroots nature of Linux is kinda gone and the suits have taken over, just like with the internet itself.
I also love how the OS is stable but the apps are rolling. This really helps to be on the latest KDE etc. And the documentation is excellent. ZFS on root as a first class citizen too.
There's a small team of maintainers working hard to keep everything going in this age of increasing linuxisms. But so far they've been doing a great job.
I just started using FreeBSD as my desktop OS on an old x230. I was surprised to find that for my use case, wine works faster and is more stable than on linux or Mac. Now I will install it on my desktop pc next.
Apple isn't really BSD. The mach kernel is very different. There's some shared heritage dating back to nextstep but it's very deep. And some userland. But that's really all.
> There's some shared heritage dating back to nextstep but it's very deep. And some userland.
The userland is pretty important. To most Debian users, Debian GNU/FreeBSD would feel more familiar than Alpine/Linux (with busybox and no GNU coreutils).
Sure it's very distinct but the vibe still feels more *BSD due to that early userland. That shared heritage runs deep. I'd also say it also feels more like Solaris/Illumos. Linux has just always had a very different vibe to it.
Is this the fluffypony of Monero fame? If so, I got into FreeBSD a bit after hearing you praise it on crypto podcasts back in 2017/18. Surprised your handle was still available on HN!
I'm using FreeBSD for self-hosting, home NAS and router from version 2.2.0. As it is my hobby projects, I don't want to migrate to Linux which is, IMHO, over-represented.
But it become harder and harder in recent years.
Reason? Docker.
Many current «server-side» products doesn't have good instructions how to install them «by hands» and is not very suitable for system-side packaging (creating port), as they have build systems designed to be used in CI with online access in build time (especially node.js-based and go-based ones, but rust goes same way).
Installation instructions, well-defined dependencies, good versioning, immutable source distribution files? Nah. «Take this Docker file and run it».
I am absolutely not pressuring anyone to do anything that doesn't feel right.
But FreeBSD can run Linux binaries without needing a VM or anything, using the built-in "linuxulator", and in recent releases this means it can directly execute Linux OCI containers.
Which is pretty close to running those same containers on top of a Linux kernel, when you're still bypassing much of the OS.
Not an OpenBSD expert by any means, but two small pieces of minor feedback as everything else you wrote mirrors my own setup and experience. Firstly, unless you are really strapped for space on say a 90s machine, it is generally recommended to install all the file sets as there can be interactions with ports even if one does not expect it (say ffmpeg needing X11 libraries). The general OpenBSD mindset is after all "Use the defaults" and the default is to install all the file sets. Secondly, the OpenBSD Handbook has a bit of a mixed reputation in the community from what I can tell. Unlike the FreeBSD Handbook, it is not an official document and I tend to rely on man pages, openbsd.org, misc@, and a few blogs I consider to be trustworthy instead.
As a final note, glad to see you have IPv6 up and running. I really should get around to it now that dhcp6leased has been in base for more than two releases.
This really resonates. Sometimes the best reason to switch tech is just to feel that spark of learning again. I build self-hosting platforms and have spent years trying to make it “easy”, even getting it to work on Windows/macOS. But honestly, the magic isn’t in convenience. It’s in that figuring it out phase imho...
When we don't have convenience and rather jump into the sea directly, we would actually learn how the stack works and not how the convenience wrapper worked. We would feel more confident in our ability to do more things without requiring somebody else's help and more.
It is this reason why figuring out this phase feels really important and lovely even, yet most people feel its hardness and leave it aside since they just want something which just works
Fortunately, for them, I think with technologies like docker/podman, flatpak, appimage etc. I feel like its already easy-ish enough.
Side nit pick but I hate when apps create docker/podman containers when they can also have flatpak, I would love to see some self hosting apps which have a gui or maybe even some cli hosted via flatpak but I rarely saw cli apps in flatpak etc.
Nice website design. I don't like to use the same stuff I use for work at home because home is supposed to be fun.
So I used to have everything FreeBSD but I've stopped using around 2020 when I've started buying computers that have different core configurations like ARM RockChip and Intel Alder Lake. I believe the term is called big.LITTLE when you have efficient and performance cores.
As of now the FreeBSD scheduler is not making full use of big.LITTLE. TBF It works and your mileage might vary and you might also pin stuff to cores but not ideal.
Meanwhile I went back to Linux and fell into the Nix rabbit hole.
I might go back once they get ULE to be able to use my Alder Lake efficiently.
I still run a server for hosting my Jellyfin and n8n, but I've honestly been moving a lot of my stuff to cloud hosting stuff. I found that trying to maintain uptime for all my services started to become a pretty huge time sink and I realized that I really didn't gain anything by hosting my blog on my own server with Nginx instead of just using a free Cloudflare Pages with Quartz.
I think it's ultimately a sign of aging; I don't really have the attention span or energy to LARP as a sysadmin anymore, especially since I never really enjoyed that aspect of computers anyway. I think my monthly cost of storage would get untenable if I tried to move all my raw media rips to the cloud (about 45TB [1]), so I don't think I'll be able to migrate my Jellyfin for the foreseeable future, but I would like to some day.
[1] Looking it up, storing 45TB would end up costing anywhere between $250-$1500 a month pretty easily, which I currently cannot justify.
I'm curious which aspect(s) became a time sink for you? I self-host a bunch of stuff myself. I can't say I never spend time on it, but it's measured in hours per year. Once stuff is set up, it just runs.
Also curious about the time sinks! Fingers crossed no issues with my services so far. The initial setup was tedious: configuring multiple services with their own configuration intricacies, and having proper backups. I am looking for something that would help reduce the setup toil, maybe something like nix?
I installed Jellyfin on my home server a few months ago but it’s already broken by upgrading to 10.11, and unusable until I restore 10.10 from backup or start over: https://github.com/jellyfin/jellyfin/issues/15027. There seem to be lots of other database migration bugs for this release and other ones.
Yeah, I've been afraid to upgrade because I've been following these updates. I'm going to wait until the dust settles a bit before upgrading because, as stated, I don't really enjoy larping as a sysadmin anymore.
I use Docker on Linux for this kind of thing (Jellyfin, Nextcloud and a few others) and updates are completely trouble free. I would never deploy complex "black box" apps like Jellyfin bare metal. That being said, I do run my email stack bare metal as I want fine control. Everything is hosted at home on my own hardware and I would never consider moving my computing to the "cloud."
Good actuarials can pull this off. They just charge enough that they can invest some of your upfront payment and use the interest to pay the staff to support you. We know how often hard drives fail, so you just ensure that you have enough interest to replace them when that happens.
If you are the only one paying upfront this is impossible as your harddrives might fail early, but if there are 1000 people willing to pay upfront we can easially handle that.
Note that I would not be surprised if this was just a Ponzi. That we know how to do this doesn't mean we are.
The answer is: they don't. It operates similar to a ponzi where they need a certain amount of new "investors" each year to sustain their scheme.
Obviously, collapse is inevitable on a long enough timeline for any company, but this scheme in particular is very vulnerable to a couple slow years in terms of sales.
Actually had I known about this two years ago, I would have considered pCloud; as it stands I bought 24x16TB used hard drives, about 288TB after RAID. That was like a $2600 investment that I don't really want to get rid of now unless I can find something considerably cheaper per-month.
I know the feeling, having recently migrated a solid TrueNAS 13.3 to a hand-built FreeBSD 13.5. The main reason was to get OpenZFS 2.3 RAIDZ expansion as storage was getting tight. It turns out to be quite similar using Webmin for GUI and BastilleBSD for jails.
There were a few hiccups, such as learning about bootloader versions, but after a few Saturdays tinkering it has been running solid and I’m very pleased.
That's similar to me, I started using FreeNAS back in the 9.x days.
At the time the FreeNAS documentation recommend installing to a usb drive. This proved unreliable, but dedicating a drive to it was silly given it couldn't be used for anything else. I had all the things I needed but I wanted to peel back the layers and this seemed like a good excuse
So I threw in a drive and installed freebsd 10 and spent a few days familiarising myself with everything, learned how to configure samba myself, learned how to setup jails with iocage (the old shell version), and finally imported my pool.
I used FreeBSD as my daily desktop for a while in the 2000s. IIRC, the package manager had to compile each package from source, but that wasn't a huge deal. Things just worked in a non-overly-clever fashion.
Just two weeks ago, I spun up a FreeBSD server on OVH and migrated a service to it from Railway. Playing with jails, pf, ZFS, and some other goodies has been a lot of fun. Since I (massively) over-provisioned, I also spun up Gitea, Woodpecker CI (and agent; blazing fast CICD is so nice), and a personal blog. Been a great learning project.
[] It's not my first time with FreeBSD. I first ran it in ~2004. But it's been over 10 years since I last ran it, and I'd forgotten a decent bit. The last time I ran it, I just set up a couple of jails for NAS and Plex and proceeded to not touch it until I moved.
Bastille is very nice to use. You can spin up a jail with a simple `doas bastille create myjail 10.0.0.1` or whatever. Bastillefiles stand in as Dockerfile analogs, if you want to go that route (you have to create the jail, then apply the template, rather than doing it in a single command).
One nice thing is cloning a jail (which can be done live if using ZFS) to spin up a dev/test environment on a different IP. Or setting up a jail to try some different configurations and not having to worry about resetting things on your main host.
I've set up a storage jail with no network access, then a couple of service jails that dip into it at various mount points/permissions. It's total overkill for what I'm doing, but the point is to learn, tinker, and have fun.
I've started using Bastille recently, it allows using Dockerfile-like 'templates' to provision jails. I like this because I can destroy and recreate the jails easily, particularly to move to a new release (without having to do in-place upgrades synced to the host version, which is how I used to do it).
The deb and rpm files are not from the application either. Someone outside the application took the application and built the deb/rpm for the distro. FreeBSD just calls their packages "ports", but the concept is otherwise the same, just download the package. FreeBSD is better that most distros as is works to rebuild some middle library yourself with non-default options and then have a leaf application binary depend on it (assuming of course that they are compatible, if your non-default option breaks the application it won't work)
Which type of applications? What I have found to be finicky is the desktop environments, however BSDs are pretty much tuned for web servers/applications. Bastille is designed for deploying web applications in jails securely and built on top of FreeBSD which is a pretty good default OS that gets out of your way already.
Normally you don't release an app for BSD specifically unless you want to offer a port. In which case software is usually built and if you need containerization you can put it in a jail.
It seems you would do well to install a FreeBSD vm/usb and give it a run. Their documentation is pretty good and their forums are helpful.
They have all of that. Flatpack is not a thing in Unix and you wouldn’t want it. If you want the terribleness of Flatpack stay on Linux. This post is about self-hosting not Desktop software.
Flatpaks, from the source if available, are excellent: you get the latest versions of the app from the official source, with permissions set for a pretty locked-down sandbox.
What’s not to like, I’m curious?
The storage is cheap these days, if you consider downloads are large. Core apps are robust.
Having never used anything beyond Linux, Windows and Mac, what would be a good starting point? Can I expect gnu/coreutils to work as is (ls, cd, pwd, et al.). Can I expect to not get bitten by arbitrary issues? What if one of the emacs packages that I am accustomed to using doesn't work there due to a dependency on something that is Linux only? How likely/possible is that?
All the utilities are not GNU, but BSD, so there are differences. But typically not a problem, as long as you move inside POSIX. Most GNU utilities (all?) can be installed if you prefer them. For example, make is typically gmake, and you really need it. I haven't used BSD for the last 10 years but used it from 1999 to 2015. I had never major issues.
Is *BSD routing performance still lagging behind Linux? On Debian 12, I can saturate my 25Gbps link between PCs (the router has a 9600X), and can push north of 4Gbps through Wireguard.
I find myself using BSDs at home too, I got a bunch of very old systems that only NetBSD supports these days. Very old SPARC, HP 9000s and the likes. Everything else is Linux, but maybe I'll try one of the BSDs on something more modern...
I have used FreeBSD back in 1999 to provide hosting services for a company that I have worked. Web server, DNS, POP/SMTP, FTP and squid cache proxy
.it was used also internally for DHCP and NAT routing (since we had only one public IP). Just configured it like an appliance and never had a problem, even uptime was counted in months (exception was package and kernel upgrades).
I prefer developing Rust on FreeBSD, memory allocator, scheduler, network stack, kqueue, dtrace and other instrumentation are all superior than the Linux counterparts. What's missing for you?
I feel like these "self-host and free yourself" articles would be better served giving us an estimate on the amount of time they spent on the process. That might help sell people more if I know it will take me 3 hours to setup a Bastille VPS w/jails for Caddy website, syncthing, Cal/Card/WebDAV, etc.
Then I can put 1.5 hours of effort into it one day setting up and getting used to Bastille and another 1.5 hours another day installing my software. Maybe my request is silly but most people say "I don't have the time or patience to self host" but what does "dont have the time" mean? Sure it's variable from person to person. It might increase interest in self hosting if people have a better idea of what they would be getting into.
This would pair well with encouraging a system like Bastille that just wants to get out of your way (two contextual views of time-savings).
Ports is a meta build system, from which packages are created. Gives a lot of convenient power and flexibility. For ready built packages, the FreeBSD equivalent of dpkg or whatever five different package commands Debian is using now would be pkg.
FreeBSD is a complete OS, while debian is a distro, i.e the Linux kernel + a lot of programs including the utilities from GNU. So almost everything in debian comes from a package while in the BSD world, there's a split between the system utilities (called base) and the third-party projects (called ports). The port system itself is a collection of recipes to build those projects.
But the nicest thing about the software in the base is that they are developed in sync with the OS, so their code can be simpler.
FreeBSD ports are more up to date. Debian packages are famously out of date - their claim to fame is stability not staying up to date. Arch is a better comparison here if you care about this you would be asking about Arch not Debian: that you are asking about Debian implies you want this out of date.
The other major difference is FreeBSD ports lets you chose the build options - the defaults are normally good, but if you don't like how Debian (Arch...) choose to build your packages you are not stuck. Ports even mixes with binary packages so you can choose the defaults for some things and build others yourself and the system will track everything and when things need to be updated. This is something you rarely need, but when you do FreeBSD soundly beats everyone else just because the effort is so much less (again though, most people never need this in the first place - and Debian has pushed less need of this on applications which is a good thing)
All of this person's problems seem to stem from a practice of implementing business style setups at home. The truth is you don't need any containerization/VMs for a home server setup. You don't need all the nines for uptime either, it's perfectly okay to be offline for a week or whatever. It's your stuff! No one else has a say. The idea that everything has to be running on a separate OS from the one you use is a killer.
You don't need to start over in a new OS for this. Just don't cargo cult. Linux can do all this fine natively without containers and without risk in very straightforward ways if you ignore all the "deployal" memes or ideas of fallbacks. Just install nginx from your repos on your desktop, throw in some .html files to a directory and play.
My wife has opinions on my servers going down. She likes all our private music to be up 100% when she is listening. (think recordings from friends - the type of things that spotify would never have)
Can we leverage AI for thr man pages and how to get things done? Anyone know if the llms are relatively trustworthy with their how to?. The assumption is because rhe man pages are well curated and the bsd's don't change much, source of truth is a bit more universal than other OS's.
The fact I miss pretty much all the drama around the latest corporate take over attempts on Linux is just icing on the cake. The toxic slug strategy is an amazing one that more open source projects should use.
One was to pick a set of norms repugnant to the mainstream that everyone currently in the community can tolerate and enforce them rigorously on all new members. This will limit the appeal of the community to people like the ones currently there and will make sure that it never grows too big.
Thus your community is as appetising to activists attempting a hostile takeover as a toxic slug is to a bird.
As an example from six years ago, when the code of conduct madness had just reached its peak:
>I believe OpenBSD's code of conduct can be summed up as "if you are the type of person who needs a code of conduct to teach to you how to human then you are not welcome here".
Nice.
True, but what you have ignored is that jerks exist equally on all sides of any CoC.
It's just as often as not that the producers and promulgators of some CoC are the jerks. In other words CoC's don't fix anything by merely existing. A few lines in a charter or mission statement already does the same to have something to point to just for formality and documentation sake.
--
[edit to expand or re-state a little...]
It's not that there is no problem and everything is fine already. It's that CoC's are almost always a thoughtless and ineffective, even actively counter-productive response to the problem.
A coc is an attempt to make an easy solution for something that there probably IS no easy solution for.
The problem takes the form of a continual fresh stream source of problem. IE a forever stream of new jerks, and existing jerks who dodn't just do one thing today but continue to exist tomorrow and the next day.
And so the solution can only be a matching continual case-by-case counter-effort, from intelligent insightful people who have good judgement.
Yeah, that doesn't scale and isn't easy and only some people do even a half-way good job of it.
It's just not a problam that you can bash script away.
But trying to do so is an example of being just a different color of jerk making life worse for others, but just in a different way and employing different mechanisms.
It's true that you can't just throw together a CoC and declare the problem to be solved. But there is value in writing down some ground rules. The purpose is not to "script" enforcement, it's to have something concrete you can point to. Having a CoC that says "no personal attacks" won't stop personal attacks, but it will let you very quickly shut down anyone who comes back with something like, "you just need to have a thicker skin."
I think that the goal of any code of conduct is to prevent any semblance of arbitrary and whimsical punishment, which can kill entire communities.
Linux unfortunately has to endure with toxic contributors and even maintainers, and history showed that when those maintainers fail to human and consequently the community banishes them, they go on a tirade arguing all kinds of conspiracies. A code of conduct is a form of checks and balances, and code of conduct violation processes serve as processes to collect and present objectively verifiable paper trails of exactly when snd how those maintainers failed to human, and how bad at it they were. Those types can't simply argue their way out of a list of messages they were awful to others, how exactly they violated the code of conduct, and how bad it was. Thus any stunt they pull is immediately rendered moot by the deliverables from the project.
Quite ironic then that CoCs overwhelmingly lead to arbitrary and whimsical punishment.
As a result of this typically CoCs are used to block contributions or block contributors from projects where the people enforcing the CoC they wrote wield it as a weapon against men whose perceived personal politics they disagree with. And typically rumours are enough to trigger CoC proceedings against them.
I don't know which codes of conduct you have been exposed to. The ones in Linux cover basic things like not being cool to attack other maintainers with posts like:
> Get your head examined. And get the fuck out of here with this shit.
https://lwn.net/Articles/999197/
This is hardly what I would label as an ideological debate.
I don't agree. I think it has been working quite well in spite of the conspiratorial bullshit excuses made up by those who failed so hard to human to the point they were slapped with one.
Nevertheless, one of the values of a code of conduct is that people like you and me can check the deliberation and hear what all interested parties had to say. Without a code of conduct, the one with the loudest voice and the more interest to subvert code of conduct deliberations could basically dedicate their life shit-talking the project.
That's the opposite goal; the CoC is to be as broad as possible while still being as vague as possible.
It's a tool that has been repeatedly weaponised against the out-group by the in-group - there is never any sense of even-handed usage of a CoC against the community.
- IDE support is an issue still
- Filesystem challenging when using a laptop that runs out of battery
- MATE lacking volume and WiFi controls
- This one is just me being picky but a GUI to help me gain a better understanding of the security settings or alternatively more up to date books.
- I am not exactly sure on how to correctly use virtualization and I need it to support docker workloads at work
> IDE support is an issue still
IMO, languages and platforms that require IDEs, also leads to complex software that is hard to maintain. The only exception is smalltalk.
> Filesystem challenging when using a laptop that runs out of battery
Easily resolved by using apmd and it `-z` flag. I think there's a couple utility out there that you can script for monitoring battery level.
> MATE lacking volume and WiFi controls
One of the good strength of OpenBSD is that the cli utilities are quite nice that I've not installed gui replacements (I'm using cwm). I don't mind doing a few `doas ifconfig` every once in a while.
> but a GUI to help me gain a better understanding of the security settings
I'm with you on that one. But the man pages are truly extensive. And the OS code is fairly readable.
> how to correctly use virtualization
Current vm solution is very bare. For docker, you'll need a linux VM, but the installation process maybe troublesome. It only supports serial interaction, which can be disabled by default in some distros.
> One of the good strength of OpenBSD is that the cli utilities are quite nice that I've not installed gui replacements (I'm using cwm). I don't mind doing a few `doas ifconfig` every once in a while.
I also don't mind doing things like this for network, but for volume this is very much an instant always-there requirement. If I need to mute/lower/raise the volumne in a hurry, I don't want to hunt for the application playing the sound, then find the volume slider on it, etc.
This is literally a deal-breaker for desktop/laptop users.
What I'd like to know, if there are any OpenBSD people reading, is how hard is it to contribute a fix or similar to make the desktop environment's volume control work?
I can obviously fix it for myself with some gui script/keyboard shortcut/etc, but I'd rather have anything be in the default installation whenever I refresh the install.
“ IMO, languages and platforms that require IDEs, also leads to complex software that is hard to maintain. ”
The truth is that I (and probably other users) don’t always have the luxury of choice and a large portion of commercial codebases have a very large number of files. Sometimes, it is multiple codebases at once with a very large number of files .
“ Easily resolved by using apmd and it `-z` flag. I think there's a couple utility out there that you can script for monitoring battery level.”
Yeah but I don’t want to accidentally lose data if I shut the lid and accidentally forget to plug the thing in for a few days . “ One of the good strength of OpenBSD is that the cli utilities are quite nice”
I don’t want to enter and exit a cli tool in order to increase and decrease the volume . Ideally it’s a control in the top right or a keyboard mapping . What if something loud begins playing in a browser tab and I have to change the volume quickly?
> IDE support is an issue still
Yes, I agree. I enjoy using VSCode for most projects and there is no native support today in 2025 as far as I know. It is possible to use the web version (vscode.dev), but naturally, this lacks some features of the desktop application.
Typically I use some lightweight editor like Leafpad which has some basic IDE features. Not a replacement for a real IDE, but just an idea.
> Filesystem challenging when using a laptop that runs out of battery
Yes, OpenBSD uses FFS2 as the default file system. It's a solid filesystem with extensive history and testing, but it's not particularly tolerant of sudden power loss. In my experience most OpenBSD systems will come back online automatically after power loss, but there is a risk it will drop into single user mode if `fsck` wants a human in the loop.
There are some things one can do to help mitigate this, granted it's not very appealing coming from a more fault tolerant journalling FS: automated backups, using the `sync` option on your main data partitions (can affect performance), and of course monitoring power as mentioned.
IMO, this is a bit easier to manage on desktop or server roles where one can put everything behind a UPS.
> MATE lacking volume and WiFi controls
I haven't used MATE on OpenBSD. It's possible it's a combination of hardware + OpenBSD + MATE if it's not working. I know I have had working media controls on OpenBSD laptops in the past but I tend to stick with older laptops, Thinkpads, etc.
There are some in-base utilities to probe media keys and hook into X etc. if you're open to scripting a bit on your own hardware.
But yeah, after using Linux on laptops, it would be annoying for media keys to not Just Work after installation.
> This one is just me being picky but a GUI to help me gain a better understanding of the security settings or alternatively more up to date books.
Fortunately, there aren't too many security settings to change on OpenBSD. The most common one for laptops would be to enable SMT, e.g. enable hyperthreading on CPUs that support it. It is disabled by default as SMT is difficult to secure properly, but it does naturally improve performance. The command is `sysctl hw.smt=1`, or `echo 'hw.smt=1' >> /etc/sysctl.conf` to make it permanent.
> I am not exactly sure on how to correctly use virtualization and I need it to support docker workloads at work
Virtualization is a little unusual on OpenBSD. It's not quite as flexible as qemu, FreeBSD jails, bhyve, KVM, etc. The `vmm` and `vmd` systems were built in-house by the OpenBSD team. It is currently limited to just one core per VM the last I checked, and only supported serial and not VGA, so no way to run Windows under it for example.
I have had great success running Alpine Linux under OpenBSD and then running Docker on top of that, which opens the door for many tools and apps to run under an OpenBSD hypervisor.
There are also some VPS providers out there that fully dogfood OpenBSD and run their entire VM architecture on OpenBSD, such as OpenBSD Amsterdam, so it is totally viable depending on what one needs to virtualize.
Of course, one can run qemu on OpenBSD and virtualize whatever the heart desires.
---
That said, while OpenBSD can be a great laptop OS, it can require a bit more setup and understanding compared to a mainstream Linux OS. IMO it's still worth playing around with, even in a VM or on different hardware (desktop, Raspberry Pi, etc.) just to see the OpenBSD way of doing things, because it is truly a wonderful OS to use and learn. Other OSs start to feel a bit clunky to me after using OpenBSD for a while. :)
I thought it was about the parallel ATA. And I tought "who uses that still?!" but is about IDEs for programming...
sorry about the topic deviation, but I laughed hard.
One of the reasons you don't see a lot of books around OpenBSD (aside from the very small userbase) is that the built-in documentation is so good. The manpages are actually worth reading, and for the more complex services, include examples and additional reading.
But still, the rest of your points are very true. OpenBSD is really not for everybody, but I think that's one of its strengths. It works extremely well for the people it works for, because it's not trying to coax new users into the fold.
Also, you know, like you don't have to use OpenBSD for everything. I still have plenty of Linux servers, and Linux computers, because there are some things OpenBSD is not suited to.
So much linux software doesn't come with sane defaults out of the box, doesn't have an easy path to common desired configurations, and doesn't have reasonable documentation. PARTICULARLY for "open" software that has a paid hosted option.
I say this after decades of a career where a very large proportion of the frustration and "stupid work" I've had to do involved getting a piece of software to do something obvious.
Working with the BSDs is just delightful in how wanting to do something turns into something working with ease.
And otherwise, I don't know what software you're thinking of that is easier to deploy on BSD than on Linux.
To be blunt, the only reason this is a problem on Linux and not BSD is that no relevant software runs on BSD at all.
Not too mention that some newer servers you might want to run are containerised and have few, if any, instructions for how to set them up without containers.
Time and attention are always in short supply.
For me, the balance between all the overhead of the "cattle, not pets" approach and the manual way is the a README.md file for basic setup, and then having Ansible stand up the rest of the configuration. The host is configured as a Jail host, then individual services live inside the jails. Creating and configuring the jails is also done through Ansible. Overall, I really like the setup. I can individually SSH into each jail to allow easy debugging, I can snapshot the jails, and data lives on a special ZFS subvolume that I mount into each jail at "/bucket". This way, I can throw away the jail at any time, fire up Ansible, and have everything up and running again in no time.
If you don't know about them already, you may be interested in service jails (forthcoming[1] in 15):
> A service jail shares the complete filesystem tree directly with the host (the jail root path is /) and as such can access and modify any file on the host, and shares the same user accounts with the host. By default it has no access to the network or other resources which are restricted in jails, but they can be configured to re-use the network of the host and to remove some of the jail-restrictions.
* https://docs.freebsd.org/en/books/handbook/jails/#service-ja...
* https://docs.freebsd.org/en/books/handbook/jails/#service-ja...
* https://man.freebsd.org/cgi/man.cgi?query=rc.conf&manpath=Fr...
[1] https://www.freebsd.org/releases/15.0R/schedule/
But it's very cool to see continued development, jails are such an awesome feature!
These days I have my FreeBSD server providing NFS for a k3s instance on a different box.
- firewall? Lots of pain and hard to find friendly, best practice starter templates. Wherever I looked, people said "it's complicated." After a lot of tinkering and learning I finally got a setup that was pretty safe. (I think.)
- pm2 was buggy on FreeBSD because of some issue with process IDs getting lost. That was pm2's fault, not FreeBSD's. But I still wanted to simply run different processes and keep my logs somewhere. Well, I guess I could write rc.d scripts for that. But keeping logs from the processes started by rc.d scripts? That also appeared to be a world of pain, and wherever I looked for answers people said "it's complicated."
In the end, it was just too much having to re-invent the wheel for common server tasks and I had to say goodbye. It's not you FreeBSD, it's me. I'm just not an OS dev.
I felt this way about pf when I first got PF going around 2011 for my home router/firewall box. Not saying this is the same for you or anyone else, but my issue was that I was approaching it from the point of view of “I want to configure a home firewall router with PF” instead of “I want to learn the fundamentals of what a firewall does”.
It took me a few more years to get well-versed in all that stuff: the structure of packets, what NAT actually means (what addresses are being translated, why, and where), what's going on in the state table, how to debug when things aren't doing what I expect, etc. Once I did it became much more straightforward to express in my `pf.conf` what I want to do, but you're right that doesn't really help new users.
> Lots of pain and hard to find friendly, best practice starter templates.
FreeBSD does include this, however! It's just implemented using IPFW instead of PF. Check out `firewall_type` key in `rc.conf`: https://cgit.freebsd.org/src/tree/libexec/rc/rc.conf?id=edad...
For a very simple NAT gateway, one could set `firewall_type=simple` and then `firewall_simple_(iif|inet|oif|onet)(_ipv6)?` to configure the ISP-side and internal-side interface names and IPv4 and IPv6 network ranges for each.
For a very easy single-machine firewall, one could set `firewall_type=client` or `firewall_type=workstation` if you want to host anything. For the latter, `firewall_myservices` and `firewall_allowservices` control what ports are enabled and who (other networks/IPs) have access to them
For more details and to see exactly what each option actually does, check out `/etc/rc.firewall` where this is all implemented: https://cgit.freebsd.org/src/tree/libexec/rc/rc.firewall?id=...
I don't use much FreeBSD these days, but pf (from OpenBSD, I know), is one of the best things since sliced bread.
In my first job I was working for a company selling a third-party vertical software and we were proving support for it. We were using a very expensive symantec vpn with most customers connecting with a 33.3kb phone connection, until we reached the license limits, and there was no money for new licenses. In a pinch, me and a coworker set up a new server with openvpn, freebsd, pf, and a ruby-based dns server that I don't remember anymore, and we grew an order of magnitudes more customers.
It's been more that 20 years, I still don't know how to use firewalls in linux, (there are many, I just pretend they don't exists) but I would still be able to setup a pf firewall if needed. I need to say it again, pf is a joy to use.
My gripe with FreeBSD right now is that I miss something like docker swarm. bhyve is fine but AFAIK it works only on a single host. Give me something that works on a bunch of hosts, and I will come back right away
Edit: I think it's 'vm migrate'
https://man.freebsd.org/cgi/man.cgi?query=vm&sektion=8&manpa...
PF seems to me like pretty much the most well regarded firewall there is - with a nice, sensible DSL for config. If you don't like like it, you can use use IPFW or IPFILTER, which are alternative, built-in, firewall front-ends.
- In the end, it was just too much having to re-invent the wheel for common server tasks
Maybe you have built your routine around a system that have reinvented the wheel? I think FreeBSD knowledge degrades more slowly than that of Linux distros.
- I'm just not an OS dev.
That's how I feel when I enter the chaotic Linux world. Do you think my life revolve around keeping up with this shit? :)
I feel that as a Linux user. I really like Linux, I use it on my desktop and it runs all my servers. Delving into forum posts to find some solution to a specific problem can be exhausting. Sometimes you get a top result from like 2011 and it is out of date so you then need to spend X minutes trying to look up something more recent.
Time passes (how much time? are the birds singing yet?) as you keep slogging through that endless sea of muck.
Finally, you run across an old post on some forum where the person not only wrote about the problem, but also the cause of the problem -- and the answer.
So you're reading along, working to once again evaluate whether your problem matches their problem. And the more you read, the more familiar it all seems... like you've been there before.
"It can't be," you say to yourself.
But you scroll back up to the top of the comment and look at the author's name anyway.
And yep, sure as anything: It was you. Six years ago, you wrote about that exact problem yourself and posted a perfectly-cromulent solution to it.
So you fix it (again), note that the birds are in fact singing, and to try to sleep for a bit while pondering your life's choices: You could have found a hobby in origami or perhaps woodworking. Maybe worked as a Mennonite tradesman producing leather goods, or as a carpenter (even an Amish one if any of that seemed too high-tech).
But you didn't. You chose this path instead. It could have all been so simple, but it isn't.
And I didn't mean to imply that FreeBSD is stale. There is big stuff happening continuously. Right now it's compatibility with Linux Wifi drivers, which will make FreeBSD more laptop-able. And pkgbase, which brings some of the compile-your-self flexibility of FreeBSD to binary management, and merges the two tools that decides what makes up your system into one. And kinda makes FreeBSD into the slim system that people already claims it to be.
My pet conspiracy is that pkgbase happened because the powers that be didn't want the 1000 battles to remove junk. Any time anyone wants to remove something there's always one or two guys on the mailing list claiming their livelihood depends on not having to do "pkg install Ø". With pkgbase its all gone.
Not sure what things are like now though - I'm guessing it's much better as pf was obviously the best option :)
* PF was imported into FreeBSD from OpenBSD, maybe it had problems at first.
* Both implementations have been actively maintained, further developed, and diverged.
* There is now collaboration in the development of the FreeBSD and OpenBSD implementations.
* PF is the shit. Even though IPFW is the "invented here" firewall.
I like it because it's so stable. They don't have this Linux thing where they have to change everything around to incorporate the latest fad, and there's also not so many big tech companies constantly messing with the code. Linux has too much corporate influence for me. I don't want Huawei or Amazon to be messing with the code I run all the time. The grassroots nature of Linux is kinda gone and the suits have taken over, just like with the internet itself.
I also love how the OS is stable but the apps are rolling. This really helps to be on the latest KDE etc. And the documentation is excellent. ZFS on root as a first class citizen too.
There's a small team of maintainers working hard to keep everything going in this age of increasing linuxisms. But so far they've been doing a great job.
The userland is pretty important. To most Debian users, Debian GNU/FreeBSD would feel more familiar than Alpine/Linux (with busybox and no GNU coreutils).
But it become harder and harder in recent years.
Reason? Docker.
Many current «server-side» products doesn't have good instructions how to install them «by hands» and is not very suitable for system-side packaging (creating port), as they have build systems designed to be used in CI with online access in build time (especially node.js-based and go-based ones, but rust goes same way).
Installation instructions, well-defined dependencies, good versioning, immutable source distribution files? Nah. «Take this Docker file and run it».
It is pity.
« An introduction to OCI Containers on FreeBSD
October 31, 2025 »
https://freebsdfoundation.org/blog/oci-containers-on-freebsd...
Problem is, these prepared images contain Linux binaries. Using Linux emulation in FreeBSD for OSS project doesn't feel ... right?
But FreeBSD can run Linux binaries without needing a VM or anything, using the built-in "linuxulator", and in recent releases this means it can directly execute Linux OCI containers.
Which is pretty close to running those same containers on top of a Linux kernel, when you're still bypassing much of the OS.
I wrote about it here: https://www.blog.montgomerie.net/posts/2025-10-11-setting-up...
Not an OpenBSD expert by any means, but two small pieces of minor feedback as everything else you wrote mirrors my own setup and experience. Firstly, unless you are really strapped for space on say a 90s machine, it is generally recommended to install all the file sets as there can be interactions with ports even if one does not expect it (say ffmpeg needing X11 libraries). The general OpenBSD mindset is after all "Use the defaults" and the default is to install all the file sets. Secondly, the OpenBSD Handbook has a bit of a mixed reputation in the community from what I can tell. Unlike the FreeBSD Handbook, it is not an official document and I tend to rely on man pages, openbsd.org, misc@, and a few blogs I consider to be trustworthy instead.
As a final note, glad to see you have IPv6 up and running. I really should get around to it now that dhcp6leased has been in base for more than two releases.
Fortunately, for them, I think with technologies like docker/podman, flatpak, appimage etc. I feel like its already easy-ish enough.
Side nit pick but I hate when apps create docker/podman containers when they can also have flatpak, I would love to see some self hosting apps which have a gui or maybe even some cli hosted via flatpak but I rarely saw cli apps in flatpak etc.
So I used to have everything FreeBSD but I've stopped using around 2020 when I've started buying computers that have different core configurations like ARM RockChip and Intel Alder Lake. I believe the term is called big.LITTLE when you have efficient and performance cores.
As of now the FreeBSD scheduler is not making full use of big.LITTLE. TBF It works and your mileage might vary and you might also pin stuff to cores but not ideal.
Meanwhile I went back to Linux and fell into the Nix rabbit hole.
I might go back once they get ULE to be able to use my Alder Lake efficiently.
I think it's ultimately a sign of aging; I don't really have the attention span or energy to LARP as a sysadmin anymore, especially since I never really enjoyed that aspect of computers anyway. I think my monthly cost of storage would get untenable if I tried to move all my raw media rips to the cloud (about 45TB [1]), so I don't think I'll be able to migrate my Jellyfin for the foreseeable future, but I would like to some day.
[1] Looking it up, storing 45TB would end up costing anywhere between $250-$1500 a month pretty easily, which I currently cannot justify.
Or about $5k one-off at pCloud, which is still a big investment. (No affiliation, just a customer.)
If you are the only one paying upfront this is impossible as your harddrives might fail early, but if there are 1000 people willing to pay upfront we can easially handle that.
Note that I would not be surprised if this was just a Ponzi. That we know how to do this doesn't mean we are.
They get to depreciate the equipment, deduct electricity and labor, and get bulk rates on equipment.
And show mark to market accounting, cash flow and revenue for investment funding
Obviously, collapse is inevitable on a long enough timeline for any company, but this scheme in particular is very vulnerable to a couple slow years in terms of sales.
There were a few hiccups, such as learning about bootloader versions, but after a few Saturdays tinkering it has been running solid and I’m very pleased.
https://zvault.io/
At the time the FreeNAS documentation recommend installing to a usb drive. This proved unreliable, but dedicating a drive to it was silly given it couldn't be used for anything else. I had all the things I needed but I wanted to peel back the layers and this seemed like a good excuse
So I threw in a drive and installed freebsd 10 and spent a few days familiarising myself with everything, learned how to configure samba myself, learned how to setup jails with iocage (the old shell version), and finally imported my pool.
Years later very little has changed.
[] It's not my first time with FreeBSD. I first ran it in ~2004. But it's been over 10 years since I last ran it, and I'd forgotten a decent bit. The last time I ran it, I just set up a couple of jails for NAS and Plex and proceeded to not touch it until I moved.
One nice thing is cloning a jail (which can be done live if using ZFS) to spin up a dev/test environment on a different IP. Or setting up a jail to try some different configurations and not having to worry about resetting things on your main host.
I've set up a storage jail with no network access, then a couple of service jails that dip into it at various mount points/permissions. It's total overkill for what I'm doing, but the point is to learn, tinker, and have fun.
I never see an app released for FreeBSD. There are usually Deb and rpm files.
I suppose FreeBSD adapts and releases some them in their ports. But how is the coverage?
Another issue is the hardware support. Does it have drivers for things like recent WiFi chips?
Normally you don't release an app for BSD specifically unless you want to offer a port. In which case software is usually built and if you need containerization you can put it in a jail.
It seems you would do well to install a FreeBSD vm/usb and give it a run. Their documentation is pretty good and their forums are helpful.
If they support flatpaks, it might be good enough.
What’s not to like, I’m curious?
The storage is cheap these days, if you consider downloads are large. Core apps are robust.
GhostBSD.
https://ghostbsd.org/
This is delightful. Personal projects are a great place to buck the technical monoculture and try something unique. I really enjoyed reading this.
Then I can put 1.5 hours of effort into it one day setting up and getting used to Bastille and another 1.5 hours another day installing my software. Maybe my request is silly but most people say "I don't have the time or patience to self host" but what does "dont have the time" mean? Sure it's variable from person to person. It might increase interest in self hosting if people have a better idea of what they would be getting into.
This would pair well with encouraging a system like Bastille that just wants to get out of your way (two contextual views of time-savings).
* Ease of management - more holistically designed.
* Rock solid parts that fits together - more holistically designed.
* ZFS, jails, bhyve, dtrace, ports.
* If it works today, it works tomorrow.
* A more approachable community (which AMD says is the reason why they are developing for FreeBSD before Linux now).
* Transparency and simplicity of how it works - if you can understand it, you can manage it and fix it.
* Documentation.
* Fun! Linux is not fun.
But the nicest thing about the software in the base is that they are developed in sync with the OS, so their code can be simpler.
The other major difference is FreeBSD ports lets you chose the build options - the defaults are normally good, but if you don't like how Debian (Arch...) choose to build your packages you are not stuck. Ports even mixes with binary packages so you can choose the defaults for some things and build others yourself and the system will track everything and when things need to be updated. This is something you rarely need, but when you do FreeBSD soundly beats everyone else just because the effort is so much less (again though, most people never need this in the first place - and Debian has pushed less need of this on applications which is a good thing)
And it shows.
You don't need to start over in a new OS for this. Just don't cargo cult. Linux can do all this fine natively without containers and without risk in very straightforward ways if you ignore all the "deployal" memes or ideas of fallbacks. Just install nginx from your repos on your desktop, throw in some .html files to a directory and play.
The problem is when self-hosting amateur stuff leaks into professional life.
And then you have a expert beginner pushing their homelab/Self-hosting