Your commentary -- from a direct participant, not just an observer -- is 
very informative.  It also illustrates fundamental flaws in software 
engineering and design from a monolithic system that did not even obey 
structured language software design, let alone anything akin to the 
object oriented paradigm.  Had there been proper isolation and 
encapsulation, possibly difficult in a monolith as contrasted with a 
micro-kernel design, most (all?) of the internals developers and 
implementors difficulties you describe could have been avoided.  I am 
aware of the issues of "ravioli" design and implementation within OO, 
much the same as "spaghetti" within structured non-OO, and even worse 
within unstructured "go to", so simply using OO is not a panacea per se. 
  All of this assumes an imperative language base (such as C++) that is 
for a classical (not quantum) platform, including a classical concurrent 
platform of any concurrent architecture.

Does in fact SystemD provide for encapsulation and isolation, as in a 
proper OO design and implementation?  Could not a "proper" sysadmin 
interface be constructed to configure SystemD, rather than the 
"hodgepodge" of what seem to many as arbitrary and capricious 
incantations?  These questions are not posed as divisive or derisive, 
but instead requesting information.

On 1/23/21 4:41 PM, ~Stack~ wrote:
> On 1/22/21 8:20 PM, Yasha Karant wrote:
>> I had not heard the history of SystemD in any detail.  What, if any, 
>> were the software engineering and design justifications for SystemD?
> 
> TL;DR synopsis. It's just a tool. A tool that solves a very common and 
> VERY painful problem for people who build Linux based OS's. And those 
> developers made the decision. Not the users who, honestly, most of the 
> time don't have a clue about the pain the developers face. It isn't 
> perfect, and it causes problems sometimes in the user space. But it 
> isn't a tool for the users.
> 
> 
> I was incredibly active in the Debian community for a number of years 
> leading up to the SystemD fiasco. You can still find my posts going back 
> as far as 2002 on the Debian mailing list. The vast majority of my posts 
> are still publicly accessible (so if you really doubt what I say below, 
> you can go find my emails on the Debian archives). :-)
> 
> Most of my issues regarding SystemD are political, not technical. Though 
> I've had a number of technical problems over the years and I've filed 
> bug reports to get most of them fixed - technical is usually the easiest 
> to fix.
> 
> One thing people tend to overlook in these conversations is that systemd 
> was clearly not meant to help SysAdmins - the fact that does is a by 
> product. The point was to help system builders and integrators. EG: the 
> people building the distro that others use; the ones who try to make all 
> of the sub-services play nice with each other so that the end user can 
> just click around on a mouse.
> 
> You can think of SystemD as the the low level communication of services 
> that not a whole lot of people (developers nor users) want to do but 
> everyone who uses a desktop or server depends on to work- it's at the 
> integrator level where SystemD starts to shine. It helps a lot of the 
> underpinning communications where most users don't ever dare to tread. 
> Those dark tunnels where experienced SysAdmins have their eyes gloss 
> over at the dread they encountered upon their last traversal.
> Those places.
> 
> By the time you get up to the level where SysAdmins work or even higher 
> where the users work, most of the time SystemD is just a tool to use. 
> How you use it and how much you invest in learning it is up to you. But 
> if you are using a spanner as a hammer because you don't want to learn 
> how to use a hammer, well...good luck, but you are going to have problems.
> 
> "So it's just another tool for services to communicate?"
> Essentially, yes.
> 
> "Why all the hate?"
> Two reasons:
> 
> 1) Technical:
> Because getting all the services to talk to one another is incredibly 
> difficult. Speaking as someone who used to do a bunch of dbus level 
> programming to get services to talk to each other, the old InitV methods 
> sucked. It was painful. And every time there was a new service that did 
> things differently, it made my work harder. I particularly recall in 
> ~2008 tracing out an issue with a kernel notification to a network card 
> that caused Pidgin to flip out and spam the dbus to the point of 
> crashing other completely unrelated services because of a custom 
> plugin...gah...I was down reading hex code off the kernel processes to 
> figure that out...and it still gives me 
> wake-up-screaming-nightmares...But all the users knew was that their 
> music player would cause a kernel panic - they had no idea it was even a 
> plugin on Pidgin that was doing it because why would Pidgin (a chat 
> program ) care if a music file was played? And what did that have to do 
> with crashing the kernel?
> 
> THAT'S the low level communication I'm talking about here. The stuff so 
> far behind the scenes that the users don't even know nor care it happens.
> 
> This is simplifying it quite a bit, but if you think about SystemD as a 
> single API every program can use to communicate you get the gist of it. 
> But that API is MONSTER and its growing. So some of us old-school *nix 
> guys who have a hard time breaking the mentality of "One simple program 
> to do one simple task" struggle with something like SystemD.
> 
> The analogy I used is that for me trying to get these services to talk 
> to each other before was like herding cats. They don't want to listen, 
> they want to do their own thing, and by the end of the day I'm tired, 
> cut, and bloody. However, the alternative is the Marshmallow man from 
> Ghostbusters - one incredibly large and growing gooie monster...
> 
> MANY MANY developers who work on the underpinnings that I know prefer to 
> fight the one monster they can sort-of-deal-with vs herding cats.
> 
> 2) Political:
> The fiasco was handled badly. Distro developers made the choice, not the 
> users. Distro developers failed regularly to explain why they made the 
> choice and often either attempted some detailed technical drivel the 
> users didn't understand or told them to "shut up or leave".
> 
> The reason why I left the Debian community was because of the vitriol 
> aimed at those of us caught in the middle. Then when it started to get 
> crazy, they got ban-hammer-happy. I got banned multiple times from the 
> Debian forums (then reinstated every time because they knew me as 
> someone who helped out) because I pointed out legitimate bugs. But those 
> of us pointing out bugs were lost in the sea of outrage so the SystemD 
> guys wouldn't even listen to valid criticism and errors. The systemd 
> group itself even went into full lock-down because of the backlash so 
> you couldn't submit a bug to them at all.
> 
> Then I got "banned" TWICE because someone complained of a legit systemd 
> problem, and I responded with the answer to fix their problem. Why was I 
> banned for helping? Because, no joke, at that point they just started 
> auto-banning based on key words.
> 
> The first time, one of the devs personally reached out and apologized 
> because he saw that I was trying to help. The second time, I was just 
> done. I was sick and tired of the arrogance of the SystemD people and I 
> was sick of the rage from the users. I backed out of contributing 
> anything at all to the community for over a year. I still haven't had 
> the strength to install pure Debian again...I still get sad and angry.
> 
> Even reading through the replys others have posted, you can see the pain 
> and misery caused to others. And most of that is because of politics, 
> not technical misery. Sure, there is probably that one time that really 
> irks them. Just like I still remember that time my car sprung a oil leak 
> which abandoned me in the middle of nowhere over night and I get ANGRY 
> at that car even though I had 5 years of great reliability from that car 
> before the incident and another 7 after. I'm not faulting nor 
> diminishing that bad experience, rather reminding that we often remember 
> the worst and best while forgetting the every day mundane when SystemD 
> just did as it needed to and we didn't care that it was doing its thing.
> 
> 
> 
> These days, SystemD is just something that is there. It works well 
> enough for most people that they don't know nor care that it is there. 
> Even SysAdmins who get low into the internals like me just see it as 
> another tool. Sure, there are those who have decided that's their hill 
> to die on - more power to them. I do not want to criticize or speak ill 
> of their choices. I'm glad that they have a choice. But before I engage 
> with much more than what I've stated above, I want legit technical 
> concerns to talk about. Because honestly, right now the number of 
> systems I manage is in the hundreds and when I come across a system that 
> DOESN'T have the SystemD tools, it's often more frustrating to me then 
> all of the issues I have with SystemD combined today. I don't mind 
> talking about legit technical problems.
> 
> As for talking politics? Well, I threw in the political towel with 
> SystemD years ago. I've had enough biased politics the last few years 
> shouted at me by the media. I sure as hell don't care to engage in 
> SystemD politics any more. :-D
> 
> I hope that helps.
> 
> ~Stack~