Another daemon for managing control groups

"Linux" is just a kernel, so stuff in user-space certainly isn't "Linux".
It also certainly isn't "Unix" as that is fairly dead. It met needs in the 60s and 70s and even to some extent the 80s quite well. But the needs we have today are very different.
And it clearly isn't "GNU/Linux" as that was largely an attempt to re-implement UNIX is free software, and add more options. So it maybe carried us to the 90s.
I think calling it "Lennartix" gives way too much credit (or otherwise) to Lennart. He certainly instigated systemd and a few other bits, but the whole userspace that Fedora or openSUSE enjoy today is much more than any one person's innovation. Trying to name the whole after any one person is a mistake.

One of the big weaknesses of the "do one job and do it well" approach is that those individual tools didn't really combine very well. sort, join, cut, paste, cat, grep, comm etc make a nice set of tools for simple text-database work, but they all have slightly different ways of identifying and selecting fields and sort orders etc. You can sort-of stick them together with pipes and shell scripts, but it is rather messy and always error prone.

I remember being severly disillusioned by this in my early days. I read some article that explained how a "spell" program can be written to report the spelling errors in a file. It uses 'tr' to split into words, then "sort" and "uniq" to get a word list, then "comm" to find the differences. "cool" I thought. Then I looked at the actual "spell" program on my university's Unix installation. It used a special 'dcomm' (or something like that) which knew about "dictionary ordering" (Which ignores case - sometimes). Suddenly the whole illusion came shattering down. Lots of separate tools only do 90% of the work. To do really complete work, you need real purpose-built tools. "do one thing and do it well" is good for prototypes, not for final products.

One thing Unix never gave us was a clear big picture. It was always lots of bits that could mostly be stuck together to mostly work. I spent a good many years as a Unix sysadmin at a University and I got to see a lot of the rough edges and paper over some of them.

Systemd provides us with a clear big picture for one fairly important part of the sysadmin story: daemon process control. It may not be a perfect picture, but it is a whole lot better than no real picture at all. Back when I was being a sysadmin I would have loved something that would give me real control over all the various deamons: status, control, auto-restart, dependency etc. I even wrote something. It was nowhere near as ambitious as systemd but as far as it went, it was designed along very similar lines.

There certainly may be technical details about systemd that can be honestly debated, and there may be social/community issues that not everyone feels comfortable with (but then ambitious people often come across as intimidating), but to say that systemd is bad because it is not the "Unix way" is to simply have your head in the sand. The core idea behind systemd of unifying system service management into a single infrastructure is something that Unix has badly needed for years. It's about time we got it.
The thing that annoys me most about systemd is that I didn't write it first!