I read that message as "Whoever is the poor soul attempting to fix this system that doesn't boot, (because who otherwise inspects early boot messages?) whoever installed this system is running a known-fragile configuration."

And that's what I expect of systemd? That it should complain loudly whenever me, the daemons I'm attempting to run, or the overall system is doing things in a weird, known-bad, known-fragile way and warn me about it before it breaks if possible.

systemd is my hammer having it's own opinions about what nails I hit & where & into what & why.

I want a nail only driven half in and at some crooked angle, that's my business.

It's not my hammers job to agree or disagree that it's a bad nail hammering job as far as it knows. I don't wantto have to convince it of the validity of a use-case it didn't think of before, or thought of and decided it doesn't agree to support.

I just want that crude coat hanger and I don't care who else likes it or doesn't like it or who else thinks I should buy an actual coat hanger and attach it in some way that someone else approves of.

> systemd is my hammer having it's own opinions about what nails I hit & where & into what & why.

I feel like the exact opposite. systemd has way too many layers of customization. Things can be in /etc/systemd/system/, /run/systemd/system/, /usr/lib/systemd/system/* and those are just the "basic" override locations. And those edits and masks usually don't clash with each other, so your customizations and quirks stick, even if the rest of your system changes.

Now, if you are in a system that doesn't use systemd, if you mess with the "sacred and sanctioned" system service summoning scrolls, now you're on your own to diff whoever stuff the maintainer did, every time the summoning scroll changes, and to make sure that probably Turing-complete mess still summons a valid, working and safe system component instead of rampaging thru your system.

> Things can be in /etc/systemd/system/, /run/systemd/system/, /usr/lib/systemd/system/* and those are just the "basic" override locations. And those edits and masks usually don't clash with each other, so your customizations and quirks stick, even if the rest of your system changes.

I really encourage you to learn the difference between these three places. They are semantically distinct, and it's truly an advantage to have the system distinguish them. They're all sources of configuration, of course. But one is managed by the OS vendor, one by the sysadmin, and one by the sysadmin at runtime. Runtime isn't as significant a distinction, but having a clear, bright line between vendor-provided and sysadmin-managed config is huge.

I don't want my hammer to have a razorblade embedded in the handle so if I grab it "wrong" my hand gets sliced up.

Look analogies work both ways!

Poettering would assert that the razorblade is a part of their vision and systemd only supports modern, razorblade resistant hands anyways.

There is no analogy that worked both ways here. Some fitting counter-analogy might exist, but this isn't it, because there are no razor blade analogs in the handle analog of init.

I used hammer as the example because init is actually like a hammer. It is a dead simple impliment with limited scope and knowable, known, and absolutely predictable behaviors and properties. It doesn't actually do much of anything, which makes it infinitely flexible. By not having any will of it's own, it allows you to do more than a more complex, automatic, and integrated tool.

It can't suddenly razor blade you because it doesn't have razor blades or any other special features in the first place.

YOU are the complex integrator. And if you are not, I have no sympathy for you or whatever difficulty you have with responsibility.

You can still have complex automation and management, built on top of simpler lower level agnostic layers and tools. There was never any requirement to remove that flexibility and elegant future-proof design in order to have all the things systemd promises (and really, merely promises, it does not actually deliver any better than anything else).

Systemd is also a grand scope example of tight coupling. It's so bizarre how these supposed genius coders can commit such a huge example of something they all know to avoid like the plague in just a slightly different context.

In general, systemd-ish projects expect you to bend the system to match the project's expectation while sysvinit-ish projects are infinitely flexible to match any system (jack of all trades, master of none; worse is better; etc).

From the creators of systemd we also have GNOME, PulseAudio, and Wayland. They have some design philosophy in common.

BTW most sysvinit distros barely even use sysvinit. sysvinit is a service monitor, similar to systemd but more primitive, but typically most of what it's configured to do is to launch some shell scripts on startup. We really have "systemd distros" and "ad-hoc script distros", not sysvinit distros ("ad-hoc" is not a pejorative). I don't know why they don't make init a shell script directly - you can do that, and it's typically done that way in initramfs.

> In general, systemd-ish projects expect you to bend the system to match the project's expectation while sysvinit-ish projects are infinitely flexible to match any system (jack of all trades, master of none; worse is better; etc).

Name one thing you can do in sysvinit (or "ad-hoc script"-init) that you cannot do in systemd. With systemd, you're still entirely free to write your own artisinal shell spaghetti and jam it in alongside the otherwise clean unit structure.

name one thing you can do in systemd that you can't do in assembly code

Assuming that your comment is in good faith, that comparison doesn't work in the way I think you're trying to make it work.

systemd operates (when used normally) at a higher level of abstraction than a bucket-of-scripts/sysvinit. Especially because systemd units are declarative, this higher level of abstraction affords you (the sysadmin) the ability to more precisely specify the behavior you want. However, you can of course run scripts from systemd, so you've got whatever escape hatches you like. My question was asking if there was anything in sysvinit that those escape hatches didn't cover adequately.

Assembly, on the other hand, operates at a far lower level of abstraction. Inappropriately low, in fact. Because of this, you actually have less practical ability to specify the precise behaviors you want. For example, you'd be hard-pressed to use assembly to start a webserver after the network is up but before some other piece of software that depends on the webserver.