I'm the architect of my company's VM product. Originally it was on CentOS 6. When we had to upgrade to CentOS 7, that was a huge effort. IBM went through a similar effort with their system storage line. (We were working on a parallel joint product.)
My observation is that systemd is the "lotus notes" of init systems, it does almost everything for you, just not as well or completely as you really need and better solutions are available. I think the anti-systemd sentiment comes down to these problems: (1) Perceived "forced to take it." Many devs, myself included, didn't want to change or deal with it and felt it was being forced down our throats. (2) It breaks the unix philosophy of do one thing well instead of many things in a mediocre way. (3) Lack of perceived value. We already had init systems and tools that do what systemd did. Why all the work to change things that already work fine? (4) No real option of a "bridge." As we were porting our system from CentOS6 to CentOS7, we were trying to figure out how to modify various systems "on top of" systemd. One of my colleagues at IBM said "We tried to work around it, but if you just accept it, its easier." This, of course, was said with a tone of defeat. (5) Microsoft roots. Lennart Poettering came from Microsoft and there is a perceived "microsoftism" in the systemd design. We didn't want that corrupting our unix design ethos. (6) All in one. This is a meta of the previous topics, but having everything under the control on one system seemed to buck against the "freedom" Linux had. There are a number of other gripes, but we are where we are. I'm in no current position to create my own "init" version of Linux and need to capitalize on the environment of a standard distribution that will pass an industrial or governmental security audit. > Oh my ! It almost sounds like acceptance ! > > Despite all the naysayers on this list most times it comes up systemctl > and > journalctl have become my friends. > The reason why it's part of so many distributions is that it works. It's > well documented and consistently modular. I've had problems with > fedora,rhel, Manjiro and ubuntu over the last 12 years since systemd was > part of the linux distros and and more than one circumstance where I had > to > hack to get the system stared up. None of the problems have been with > systemd. I can remember having plenty of udev troubles back before it was > part of systemd and zero afterward. It seems systemd is a decent kernel > partner not only for loading all the demons and userspace services, also > hot loading all the hardware drivers with udev. Of course some heavy > lifting to get the system started happens before systemd starts. > > Maybe one day systemd will add a boot loader. ðð > > I am not making excuses for security issues that should not have happened > and find the criticisms fascinating but systemd for me is just there now. > > Sincerely, > John > > On Tue, Jun 4, 2024 at 3:59â¯PM Rich Pieri <richard.pi...@gmail.com> > wrote: > >> On Tue, 4 Jun 2024 09:59:25 -0700 >> Kent Borg <kentb...@borg.org> wrote: >> >> > On 6/4/24 07:07, Rich Pieri wrote: >> > > Lennart Poettering's take: >> > > http://0pointer.de/blog/projects/systemd.html >> > > http://0pointer.de/blog/projects/why.html >> > >> > Very interesting, thank you. Those point out to me that I should have >> > more sympathy for systemd, they tackled a hard problem >> >> And despite all of the problems systemd has? It largely succeeded. >> >> Which is why distribution maintainers *love* systemd to pieces. It >> solves those problems so that they don't have to do it themselves, and >> does so more or less consistently across different distributions. >> >> upstart didn't so much fail as Canonical decided to embrace systemd >> instead. And I don't blame them for that decision: much more cost >> effective letting Red Hat do all that heavy lifting. >> >> -- >> \m/ (--) \m/ >> _______________________________________________ >> Discuss mailing list >> Discuss@driftwood.blu.org >> https://driftwood.blu.org/mailman/listinfo/discuss >> > _______________________________________________ > Discuss mailing list > Discuss@driftwood.blu.org > https://driftwood.blu.org/mailman/listinfo/discuss > _______________________________________________ Discuss mailing list Discuss@driftwood.blu.org https://driftwood.blu.org/mailman/listinfo/discuss
