[cf100clunk]

From an education standpoint for those who really, really want to understand, the *BSD init and SysVinit systems require direct human administration. You break it, you fix it. Then, and only then, does learning systemd's ''then something happens behind the curtain'' type of automation make sense. If the student decides that one is more suitable than the other(s), they've done so from an enlightened vantage point.

[fragmede]

I thought systemd was fairly straightforwards, even if it does too many different things for my tastes. What's an example of it doing a too much magic behind the curtain thing?

[cf100clunk]

Bear in mind that the entire purpose of systemd is to replace a huge amount of previous system administration solutions in a fashion that is centralized and automated, and not in need of as much human intervention as previous init systems. For copious examples, look through these comments and the huge number of previous HN threads on this huge topic. That is my answer.

[fragmede]

If there are so many such instances, surely you must have one that comes readily to mind, then.

[cf100clunk]

I can do gainsaying too: surely you didn't look through these comments and the huge number of previous HN threads on this huge topic. Do your own work.

[fragmede]

https://hn.algolia.com/?dateRange=last24h&page=0&prefix=fals...

I have read the first couple pages of these results. Would like you like to highlight one of these in particular?

[its_magic]

Here's an example:

When I was building the initial version of my distro starting from a Linux Mint computer, one time I accidentally double-mounted the virtual filesystems (/tmp, /run, /proc, etc), on the target volume as my script was too primitive and didn't check the mounts first.

Exactly 60 seconds later, the whole system crashed.

Later I accidentally did this again, except this time immediately caught the problem and undid it. No matter--systemd still crashed 60 seconds later anyhow.

Or like the bug that was revealed a while back where the firmware EEPROM was writable by default in /sys or wherever it was, resulting in somebody's firmware getting overwritten and the system bricked. lol

That's the systemd life for you, in a nutshell. That sort of thing times a thousand. Not all at once, mind you--it will just take a nibble out of you here and there on and off until the end of time. After a while it will straight up fuck you, guaranteed. Which is exactly what it was designed to do.

Same with anything "Linux Puttering" touches. The guy who is now officially a Microsoft employee, as people were saying he really was all along.