[molticrystal]

While I'll ignore the System D hyperbole, your point about Unix has merit.

I think the *BSD are also good, at least from an educational standpoint, with their relative simplicity and low system requirements. Since there is a lot of integration making a from scratch distro might take less material, but it could be supplemented with more in depth/sysadmin exploration.

[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.