←back to thread

Why I run FreeBSD for my home servers (2024)

(aumont.fr)
185 points psxuaw | 2 comments | 31 Mar 25 12:59 UTC | HN request time: 0.421s | source
Show context
nine_k ◴[31 Mar 25 16:28 UTC] No.43536856[source]▶
If systemd is the reason, there are several good distros without systemd (I run Void Linux in particular).

If "kubesomething" is the reason, there's no requirement to use it. I think most people don't run it on their home servers.

If containers are the reason, then again, they are not a requirement. But they are pretty similar to BSD's jails. I don't think they are particularly complex.

FreeBSD has a number of strong suits: ZFS, a different kernel and network stack, a cohesive system from a small(ish) team of authors, the handbook, etc. But the usual Linux hobgoblins listed above are a red herring here, to my mind.

replies(5): >>43536992 #>>43541101 #>>43541384 #>>43541789 #>>43543787 #
mattpallissard ◴[01 Apr 25 01:07 UTC] No.43541789[source]▶
> If systemd is the reason, there are several good distros without systemd

I totally get avoiding systemd, I don't myself, but I get it. The author on the other hand talks about the problems doing this in a professional setting. This I do not get. As far as management of large fleets of servers goes, systemd is quite nice. Yeah, it's odd for some things but as far as automation is concerned it's the way to go.

With systemd the same file syntax and management works for services, timers, mount points, networking, name resolution, lightweight containers, virtual machines. You literally have to write one parser and serialize to ini. Then you get distribution generic management. Upgrades? No problem? Moving to CentOS to Debian? Ubuntu? arch? Whatever? No problem. It. Just. Works.

Yeah, if you're in the know you can do better for specific circumstances, but in this day and age OS's are throw away and automation you don't have to refactor is paramount. For professional work, this flame war is over.

replies(1): >>43542451 #
1. thwarted ◴[01 Apr 25 03:14 UTC] No.43542451[source]▶
>With systemd the same file syntax and management works for services, timers, mount points, networking, name resolution, lightweight containers, virtual machines. You literally have to write one parser and serialize to ini.

There is no "syntax", it's all just key=value pairs, and all the subsystems have their own set of keys/directives, and the values have their own mini-DSLs. Things that end in "Sec" (for "seconds") take duration labels. The only directives that are shared is the inter-unit dependency directives. Some keys/directives can be specified multiple times.

I don't know why you'd be parsing unit files or serializing something else to unit files. Just drop them into place. The hard part is knowing all the details of how the directives interact and what their values can be.

replies(1): >>43546811 #
2. mattpallissard ◴[01 Apr 25 13:53 UTC] No.43546811[source]▶
> There is no "syntax", it's all just key=value pairs,

This, with the sections, is INI. Duplicate keys included. Loosely defined spec, but INI none the less

> I don't know why you'd be parsing unit files or serializing something else to unit files. Just drop them into place

It's common to store information in a DB, or some other format that is easy to merge/override programmatically. Even configuration management tools like puppet, salt, ansible do this with JSON/YAML