Why I run FreeBSD for my home servers (2024)

But where does the init system end and the kitchen-sink begin? For instance do you consider networking to be part of init or is it something else. For me, I bring network up in initramfs, so it's definitely part of my init.

The only truly bad systemd-* I've worked with is systemd-journald. Which often fails to contain log entries that should be present or simply just corrupts itself.

> But where does the init system end and the kitchen-sink begin?

resolved, timesyncd, homed, journald, networkd (was very happy with Debian's interfaces(5)). Never thought of mounting file systems as process control, so also add mounting and taking over fstab. Given the ever-growing number of 'sub-systems', I'm sure new ones have been created that I'm not aware of. (I'm personally most regularly annoyed by resolved, especially as a server sysadmin where I need DNS to be deterministic, and not clever: I've gotten to the point of doing a chattr +i /etc/resolv.conf.)

I'm waiting for a systemd-mail so Zawinski's Law can be fulfilled:

* https://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski's_Law

> For me, I bring network up in initramfs, so it's definitely part of my init.

I've run Solaris, IRIX, BSD, and 1990s Linux, and I've never thought of networking as related to process control (init).

Just one example of what I like about systemd, and maybe you can call me new school, but I've really grown to like journald/journalctl.

Having systemd units automatically categorized and queryable has been very nice (the -u flag). The tag flag has also been great for me.

The --since and --until flags are godsends, I don't really care to waste time converting timestamps in my brain when all I want to do is do something like journalctl -u my_service --since yesterday --until today.

To me a way to centralize logs and have a tool like this to query them in a relatively advanced way is a major benefit.

I find that the complaints about systemd are mainly about UNIX philosphy and not about the actual functionality and benefits of those design choices. It seems like even mentioning that it's good brings back all these 2014 arguments about it.

You brought up mounting, the second paragraph of the systemd-mount manual quite clearly explains the benefit and what makes it different than the lower level mount command. And really it's not like systemd is ripping away your old tools especially in that particular case.

> Given the ever-growing number of 'sub-systems', I'm sure new ones have been created that I'm not aware of.

Found one, repartitioning:

* https://www.freedesktop.org/software/systemd/man/latest/syst...

> Just one example of what I like about systemd, and maybe you can call me new school, but I've really grown to like journald/journalctl.

Except the file format does not seem to be ACID and can get corrupted, so if the system crashes you may lose the reasons for said crash. This is strange since SQLite was available at the time, so I'm not sure why they didn't use a battle-tested, known-good format; Howard Chu (of OpenLDAP, etc):

* https://www.linkedin.com/pulse/20140924071300-170035-why-you...

> To me a way to centralize logs and have a tool like this to query them in a relatively advanced way is a major benefit.

Centralizing logs from my perspective is sending them to a central host, which last time I checked, journald could not do, so I have to run (r)syslogd regardless to do off-host log-shipping.

And it's easy enough to tell (r)syslogd to put everything in one file (which is the default on some distros) and optionally do separate file at times. With the added benefit of not necessarily having all of your eggs in one binary basket. And if you want a query-able logging API, you can do that too:

* https://www.rsyslog.com/doc/configuration/modules/omlibdbi.h...

* https://syslog-ng.github.io/admin-guide/070_Destinations/270...

> I find that the complaints about systemd are mainly about UNIX philosphy and not about the actual functionality and benefits of those design choices.

My complaint about systemd is about tight coupling between components. If someone finds limitations with (e.g.) journald, how do they swap it out or write a replacement? If the systemd folks want to have their own logging system that's fine, but why won't they architect things so it can be swapped out?

> And really it's not like systemd is ripping away your old tools especially in that particular case.

You mean like udev which used to be in a separate repo but the systemd folks took and tightly coupled?

* https://en.wikipedia.org/wiki/Udev#History