Putting this in a separate comment thread to avoid filling up the other one. I have some extra time so I read your blog post and wrote some comments. There is very little in there that is any kind of actionable issue.

>Sure, you can pipe journalctl into grep, but what if you want to use inotify, or tail a log, or expose logs over a network share? Well you have to learn the systemd-specific solution, instead of just using the tools that work with every other file.

This is absolutely not different from any other tools to manage structured data, like any database. I don't see anyone complaining that postgresql doesn't follow the unix philosophy. Logs are actually structured data, any adherence to a philosophy cannot change that fact. Actually a lot of those "standard" unix tools specifically exist to parse unstructured data into structured data, so from that perspective, having the format already in a structured data format is only there to save you some typing.

>I could complain about service files being spread all over the file tree, instead of in one central obvious place, but as I understand it systemd has some reason why that's better for them and that's fine.

The reason is straightforward. /run/ is for temporary services. /lib/ is for immutable service files shipped by the OS or by programs. /etc/ is for service files defined by admin configuration. /home/ is for service files defined by user configuration. This is all standard filesystem stuff that systemd is following. Actually, it is the old-style inits that break convention by putting everything in /etc, causing bugs in the process. The package manager should not install files to this folder that are not intended to be modified, doing so is sure to cause things to break whenever you upgrade a package. What seems like a "simple" solution in this case is actually too simple to the point of being broken.

>Unfortunatly the built-in OS image was not running systemd, and the kernal was several revisions out of date. While I had no problem getting a debian chroot running, all of the services were designed to run under systemd, this made the whole project much more of a pain in the ass than it should have been.

Well I don't see what this has to do with systemd, this would happen if you want to use any program or driver that depends on a new kernel version. Systemd cannot really do anything to solve the fragmentation caused by embedded devices running ancient kernel versions, that is very much a Linux-as-a-whole problem.

>I took the boot media out for trouble shooting, but when I systemd-nspawned into the host to try to address the problem, I discovered that journalctl would segault. Thankfully /var/log still had all the entries I needed to fix the problem. This appeared to be a general issue with running journalctl using qemu-static and binfmt.

A segfault sounds like an actual unintended bug that should be reported.

>By default systemd will kill long-running processes when I log out. Processes like screen or tmux.

Nit pick: this is not systemd doing this, but logind.

>The intentional and willful breaking of screen and tmux was to fix a GNOME bug of GNOME not closing up as it should when the user logs out

No, this is extremely wrong. GNOME cannot actually do anything about this, if a random nohup processes decides it is going to try to keep itself open.

>There's now no way to, by default, keep a program running in the background without a live ssh session.

The default is a flag in the config file that distros get to decide. There is nothing else they can do to accommodate you here, besides do what they already have done.

>For some reason my mother's computer can no longer resolve DNS. Ripping out systemd-resolved seemes to have fixed it, but note before I lost a few more hours.

>I used to think the systemd hate was silly... until I tried to get a VPN running and realized that all my DNS requests were going through a mysterious local DNS server

Unclear what is going on here without additional info. Copying more random comments that say vague things like "it doesn't work" is not really useful or meaningful to anyone. You could fill an entire book of comments like that made about everything in Linux over the years. It might be humorous, or interesting for historical purposes, but it won't help get any outstanding issues fixed.