[hxelk1]

> you can actually declare startup dependencies and other useful relationships

In theory, yes. In practice, I had a lot of trouble ordering things correctly in non-trivial cases.

> it's quite annoying that the armchair linux experts complain about how "lol systemd is so stupid for reinventing the wheel, give me my shell scripts back"

I can only speak for myself, but I don't want the abysmal sysvinit scripts back. I just want a simple process supervision suite which is true to the UNIX way of doing things. The sysvinit/systemd dichotomy is false.

Runit and s6 are both very real alternatives to systemd. They lack a ton of features, but they are a way to reliably run services. They do use shell scripts, but not for the reasons sysvinit did. They are extremely simple and have a very small attack surface as a result. Runit itself is a spiritual descendant of daemontools which predate systemd by great many years.

The problem with systemd is that it's a mediocre solution to many problems. UNIX deserved better.

[Edit: whitespace]

[mid-kid]

In a similar vein, systems like openrc use "shell scripts" as well, but can generally be written declaratively[1]. This provides greater flexibility when it comes to creating one-shot services or services that require a little setup before running, as you can just re-define the start() function, rather than requiring one to make a separate shell script for it, or dependency tree, like you'd have to in systemd land.

"sysvinit" is an ill-defined concept, anyway, as every distribution had their own scripts and tooling around actual services, and sysvinit was generally only responsible for starting getty and launching the distribution's actual service system. How initscripts were created and how you managed them depended significantly on the distribution.

[1]: https://gitweb.gentoo.org/repo/gentoo.git/tree/net-vpn/tails...

[declarethroway]

Debian's sysvinit scripts can also be declarative. https://github.com/DanielAdolfsson/ndppd/blob/master/ndppd-i...

The full system also cares about dependencies and parallel running. And this is not recent, but the black legend will never die.

Bonus: by having the shipped scripts under /etc, tools like etckeeper can show your changes as well as updates, all in one place.

[jauntywundrkind]

The other pieces are also pretty excellent. Ifup gave me no joy & was very limited. Systemd-networkd is a wonderful option with vast & great capabilities, that meshes well with the init process & it's style. Systemd-timesyncd is fine, I dunno, works for me. Systemd-journald is probably the weakest of the batch but mostly because it's not very ambitious; I loath that there's no way to really deal with super-active programs hogging all the logspace, short of configuring a second journald instance for that program, which ain't no joy to setup. Systemd-home is a cool set of features for portability. Systemd-nspawn is a bit ahead of its time & looks a little weird now but was a very novel & powerful thing to have built in to most systems. Systemd-resolved is a pretty good local DNS that handles mdns and much weirder cases easily. Systemd-boot is a really nice easy to work with uefi boot loaders that's worlds easier to deal with than uboot or gasp grub.

All of these are taken em or leave em. But they're good expectations to have. I love the bazaar model, but Linux used to have so few common expectations, used to manage various bits so poorly. And now there's a much better base of capabilities, which have universal patterns of management that tend to apply to them (how etc files are laid how, being dbus and maybe varlink accessible). Linux hadn't been growing; when you came to a random systems you expected enormously little and typically got it, and what extras were available were scattered/random and often not particularly high quality or capable software. Systems has extended a much bigger base of competency & capability. That we can plug in a USB drive and systemd-home can create an isolated dynamic user out of that & let that user securely run their environment there is a neat as heck expectation. That our network manager supports setting up such a wide range of bridges and tunnels and taps and tuns is fantastic, is excellent. I don't have words for people turning their noses up at this better world; this is so much more competent & capable a world than where we were, gives us so much we all can now take for granted, and it's been done smartly, more mono-repo than monolithic, such that you can do alternatives. But many of these pieces are utterly without peer. And the consistency of operation you get, the predictability of use, from being under the same umbrella, is an ergonomic wonder that is unmatched.

[ghostpepper]

Is there a good overview of these pieces and what they're responsible for and how they fit together?

I had a quick skim of the docs on systemd.io and there are quite a few documents but they don't seem particularly organized and I couldn't see a good architecture overview.

[mattpallissard]

I hate to be this guy but the man pages have it all

  man -k systemd

There's some terminology to learn, but overall it's pretty approachable.

Edit; and as far as architecture goes they are all _separate_ programs. It's not a single large "systemd"

[intelfx]

> The problem with systemd is that it's a mediocre solution to many problems

[citation needed]