What is so bad with systemd?
 

I have been reading lots of hate about systemd, but why?

I have implemented systemd in my LFS, before the LFS systemd book was made. Just because I want to try it, and I didn't want to spend time writing my own boot scripts before I got my LFS build scripts working.

Now my build scripts is working, so I have plans on updating them to the latest LFS release (or maybe current dev book). But before that I need to decide if I'm going to hang on to systemd or change. I really do like BSD init.

So, what is wrong with systemd? discuss! no flame wars..

For me and why I was agitated by Systemd, a lot had to do with the way Systemd was rushed into Fedora which I was using at the time. Compared to GRUB2 which was a demo project in Fedora for years, Systemd was on rails. Within a year of Lennart Poettering's initial announcement of Systemd (which I now cannot find), Fedora planned to replace Upstart/SysV with Systemd in Fedora 14. But the devs were nervous, chickened out, and delayed it to Fedora 15. I remember reading comments by Lennart somewhere about that at the time. He was pissed since he had worked hard to get it ready for Fedora 14. Six months later, Fedora 15 was released with Systemd as the default.

When Fedora 15 came, in addition to me having to learn a bunch of new stuff that I was not interested in, Systemd made my computer reboot about half of the time when it was shutdown. I would shutdown, get up to leave, and the thing would turn back on about the time I got to the door. I never figured that out. I even found comments by Lennart to some others with similar complaints, and he had nothing to suggest other than some scheme to generate a shutdown log to sift through. I ended up figuring out a way to install Fedora 15 starting from a minimal system without using Systemd. And it worked, too. But I had to maintain the SysV scripts myself with rsync after every system update because the various package maintainers were beginning to make their update rpms delete their old SysV and Upstart stuff (and Fedora was making them do that, or else). Systemd is not just another package. It's a core component probably second only to the kernel.

So Lennart was pissed that Fedora delayed Systemd. But by now, I was pissed that it hobbled my erstwhile solid system. I left Fedora forever. I stopped merely thinking about LFS and started building it looking to gain back the feeling of control I thought I had lost to Systemd. I never went back to Fedora, and I've been using BLFS for several years. Now, Systemd is muscling its way into that.

I guess the short version of all this is: I didn't have a problem for Systemd to fix. I didn't ask for it. It was forced on me. It gave me new problems. It wasn't transparent or user-neutral. I couldn't get rid of it or work around it. So it bugged me. Still does. BTW, I highly regard Lennart Poettering as a person and Linux contributor.

P.S.: You probably should edit your thread's title to mention LFS or it might get moved (in case it matters).

Good luck to have a discussion about systemd without flamewars...

I hate it because it is so terribly bloated. I don't need all that crap, and I want to keep my system as simple as possible. I have written my own initscripts in bsd-style.

I left Arch because of systemd, and I really loved Arch until then...


Actually, the reason I hate systemd is not because it is bloated - there are other blotware that I don't waste energy on hating, I just ignore them. The real reason I hate systemd is because it is like a religious mission trying to force it upon everybody.

if you really NEED the old init system
install the legacy RHEL5 or the current RHEL6

Linux From Scratch still uses SysV, but now offers Systemd. I think the OP has built both versions of LFS and now just wants to read some opinions before deciding which way to stick with.

Systemd offers no real benefits that are not currently available through the standard system other than controlling the OS through a sealed interface-less hyper-visor in PID-1.

All the touted features of systemd are available as modular units.

sysvinit, OpenRC, or Runit
pm-utils
inetd
acpid
sysklogd
watchdog
cron
atd
consolekit
eudev
libcgroups
perp, daemontools, or Runit
dhclient, dhcpcd, or networkmanager

Basically put, it's all those tools in one toolkit in a sense MACified to make things easier, but with an extreme level of complexity that isn't warranted, needed, or required by GNU/Linux.

On paper it's nice, but in practically it's vastly overbloated because it requires extras from BLFS that may or may not be needed by an administrator and could lead to potential security hazards. The very fact it becomes a hard dependency within the system is another bad problem. In order to remove systemd, you basically have to scrub the system and rebuild it all over again. It also claims to be sysvinit script friendly, but it's not. All service daemons have to be redrafted using service start files and can not truly use sysvinit scripts unless called because the service manager will not assign a socket to that application.

Systemd basically is a clone of what Sony Computer Entertainment did with their PlayStation 3 Operating system with a locked hyper-visor that only allowed privileged software access to underlying resources, which was very little, if any at all.

Plus, there is another factoid...

Systemd is far from completed featurewise... when completed it's entire ultimate long-term goal is to completely eliminate the need for the current GNU operating system, shell interfaces, compilers, libraries, and other kernel handling toolkits. Basically put... Linux OS (or systemd-OS if you want to be technical).

Plan9 actually has done this with UNG/Linux, but on a more modular scale that is at least backwards compatible with GNU.

Take a look at this thread, and particularly the link in the first post.

http://www.linuxquestions.org/questi...rs-4175500369/

Yeah, already saw Frank, and from what I've gathered from backtracking through the mail there, Kay and Lennart are on thin ice trying to hijack kernel commandline functions which is a major no-no of kernel developers. Not only that but it seems Linus has nicer things to say about Nvidia compared to how he feels about Lennart and Kay not fixing stuff and letting bugs pile up endlessly, as well as their attitudes towards problems and code submissions.

I honestly wouldn't be surprised if they actually start a war with the Linux developers and Linus and the developers just start going through the code base and dumping out udev and systemd derived code, and in the end GNU/Linux goes back to DevFS and Hotplug. I could imagine how Red Hat would deal with both Lennart and Kay in terms of their employment with them as well.

It also appears kdbus got quickly put to death as well due to all this.

We all better start dusting off our archived sources and patch set for DevFS and Hotplug, because at this rate, them, HAL, and all those other long dead projects we used to use in GNU/Linux may need to be forcibly revived. I've already been scrapping up the sources for each and all known patch sets to work on getting them compiled, and updated for newer kernels, rule sets, and other stuff.

Whatever the rate, this isn't over, and the fireworks have yet to fly.

Exactly this ^ altough I have missed all the "war" going on against systemd

I sure as hell don't like their attitude towards bug reports discussed there... looks like systemd is going bye bye

Okay, so Udev extracted from Systemd was out of the LFS book and Eudev was in (for a few days). Now Eudev is out and Systemd itself is in. But SysVinit will still be there and scripts will be used to configure the system for one or the other, I guess.

http://news.gmane.org/find-root.php?...02%40gmail.com

systemd will not be going in my future builds. I'll keep eudev and all info on it with a buildscript. I refuse to poison my system with that garbage.

Bruce shouldn't be playing fast and loose with systemd being it's still technically in development and isn't near a stable long term release.

If needed guys I'll draft up a hint we can see about getting stickied here for anyone willing to avoid using it. I still have my eudev book, and it looks like I'll be keeping it for some time unless Bruce recants this decision.

From a purely technical perspective, it's not very modular and creates lots of dependency by absorbing other things in non-modular ways. That, by itself is very contrary to the traditional UNIX philosophy of focused, modular and simple. There's been a lot of feature creep in that whole project.

It can be said that all of that is normal to overhaul processes in software development, and that it will eventually shake out. However, there are serious personality clashes between some members of that team and large portions of the Linux community.

Personally, I don't use systemd because I tried it on Debian and there was no noticeable difference to me, other than it changing the way some things work that I didn't see a need to change. But, I run in console mode most of the time, and the real difference is supposed to be on the desktop.

Why do I run in console? I hate X, always have and always will. That's not to say I hate GUI's, I've used plenty, and liked them. X I hate though... really, really hate it. Even when it's not buggy, it's still flaky, things like text-selection and whatnot... drives me nuts.

One of biggest beefs I personally had was how LP said BSD was a irrelevant toy OS when everyone who knows the history of GNU/Linux all know BSD was responsible for GNU/Linux being born as well as one of the breeding grounds for a lot of software for modern Linux.

BSD has contributed a lot to GNU/Linux and he takes those contributions far too lightly.

The other beef I have is how falsified the supposed backwards compatibility with sysvinit scripting is portrayed by LP and crew. If you don't use systemd exclusively you don't get service daemon management and you end up with a huge dependency pit as well as a vast amount of unnecessary software cluttering the system unused.

The Gentoo people saw this.

On top of that his sheer attitude towards UNIX on the whole is extremely condescending and his willingness to trash POSIX, one of the standards that GNU/Linux has a goal towards, as well as the philosophy of UNIX as quoted by Doug Mcllroy, leaves me to wonder how such a reckless buffoon could have ever gained such a following.

One thing that angers me is that hardly any GNU/Linux distributions attempted to use more sound init alternatives like OpenRC, s6, Runit, Upstart, and other 3rd party init solutions which do the same thing as systemd (parallel daemon startup and management) but aren't a dependency pit, allow full sysvinit compatibility and compliance, and have unnecessary software if you opt to use sysvinit.

Their willingness to abandon POSIX will have bigger implications later when people start running into issues porting things from OSX.

Exactly and with Apple's launchd now being open sourced out to the public, launchd could in fact be utilized as a Cross-Platform system management daemon. FreeBSD even has a work-in-progress port of it to possibly be used as an alternative to bsdinit+devd+hald that's starting to show some weaknesses. If launchd can be ported it would bring a full featured daemon manager and init system to BSD that is very well established. It could even have a Linux port if work is done.

Boycott systemd:

http://boycottsystemd.org/

I know things change, and you have to be adaptable. I can use systemd. I've already gotten familiar with it as a systems administrator.

But, IMO, it's an over-complicated piece of shit. The fact that it takes over my logging daemon and stores it as a binary only readable by journalctl irritates me more than I can explain.

F systemd. It is not the solution.

In fact, I have found no situation where SysV init scripts have not served their purpose perfectly.

I don't mind it all being bundled together. I do mind the lack of modularity. Best guess is setting that up is "too much trouble." If it had something along the lines of:

./configure <normal stuff> --with-system-logger --without-coredump-mgmt --with-alt-ipc= --without-network-ctl --use-posix-libc

etc. etc.

It wouldn't create nearly this much rage.

Every piece of systemd is easily duplicated by stand-alone packages which, in my opinion, makes it useless.

One of the key arguments has been service management and parallel daemon loading. If this was the chief arguments we could have enmass started using s6 and Runit which as init systems offer this feature set. Everything else could have been pushed back out to inet, ConsoleKit, eudev, etc. Runit and s6 are even POSIX compliant and fully support usage of sysvinit daemon start scripts if a run-file doesn't exist yet. They even can work with existing sysvinit scripts to further uncomplicate the boot process until Stage2 when they parallel load everything else in the service listing.

Yes it's over bloated and honestly, in my opinion, more effort into getting s6 and Runit pushed out should have been made, or even push perp for sysvinit more, but it's too over bloated and far too complicated to be really beneficial to the people it's aimed at which are the people who don't use Linux to begin with.

Binary logs that are readable only by Journald was a terrible idea. If you have a system failure and don't have a duplicate logging package to generate non-binary text logs and you have to enter via chroot, you're screwed because Journald can't be ran.

I disagree on the last part, and the reasons are listed in a previous mention. But I like your configure idea!

And I totally agree here:

Each person is going to feel differently about it, depending on their role. I can't imagine that programmers are going to like it, and sysadmins CERTAINLY don't like it because it is such a big change for such little gain. Its like retraining for no reason.

You can simply run journald from your live-system and use the --root= option of journalctl to attach to the log of the installed system.

Don't know what sysklogd or whatever can't be modified to use the gzip library or whatever before saving; If space is the concern.

Yes but you also have to have the host for the chroot able to use systemd tools also. I doubt many servers or users are going to have a dual-boot just for this purpose. There aren't too many live medias that offer systemd on optical media, if any. I think most still use BusyBox and mdev. I do know from when I was playing around with it, systemctl would not work under chroot period, and Journald needed systemctl running to work last I tried it.

To me binary logs are a waste. Text files are able to be read by any OS with any text editor from kwrite to Windows NotePad. Plus, exporting the log seemed very problematic also. I couldn't get it to work.

And yes, adding a gz, bz2, xz, or other compression technique to sysklogd wouldn't hurt, but having it also flush the old log and rewrite it upon reboot would be good too. Though then again, since when do text files get that unmanageable? You could even script it to run gzip at shutdown on the log file to export it before the system drive is remounted in RO mode.

I want to point out, as someone who does large scale systems management on Windows platforms... Stuff that is binary formatted is a pain. I understand that its unavoidable in some places. But, if you get a corrupt text stream, some of that can still be useful. If you get a corrupt binary file and you try to use the reader, you get really helpful stuff like:

The file format is invalid.

Windows Event Viewer is a pain to deal with as it is. Opening a sysklogd log is doable in anything like emacs, vi, nano, etc. text editors. Its nice, and ultimately better, to have simple tools able to do multiple things. I prefer text file logs to be honest. So much easier to deal with.

Interesting. I've often wondered when we would see a formal call for a boycott. However - what of the last resort to migrate to *BSD? Linux is GNU and BSD is not. What does Richard Stallman have to say about all of this?

Perhaps it is still important to keep (real) Linux alive through Debian et al. Recently (not sure when) the sysvinit package in Jessie changed to a metapackage whose description reads "This package is an essential metapackage which allows you to select from three available init systems in Debian (sysvinit, upstart, systemd) while ensuring that one of these is available on the system at all times." I fear this will go away before Jessie goes stable, but perhaps efforts (even if third-party) to keep this functionality could go a long way.

Also, who is going around Wikipedia changing all of the Linux schematics to have systemd as PID1? Usurping the operating system - and now a supposedly unbiased encyclopaedic description of it - this is getting way out of hand. The one figure on the cgroups page very explicitly implies that Linux != POSIX-compatible. A figure on the main Linux page ("Free and open-source-software display servers and UI toolkits.svg") seems to promote a VERY future-oriented, wish-list attempt at what looks like a different operating system than any distro in existence right now, with a convenient showcase of RedHat software. These people are SICK and it's time to organize and not just complain.

I've noticed it too, but Wikipedia often runs consistency checks and administrators do check for inconsistencies and will revert pages as needed.

Yes, it is time to issue a formal boycott, and it's time that other than my effort to get eudev going, we get someone to get a more viable UNIX init solution, other than SysV created and get formal scripts drafted and mass produced and started officially in LFS.

We have Runit as a better alternative, but Runit scripts are needed desperately. Runit's website already has all the information we need to get a proper hint drafted, but we seriously lack a generalized script set that can be used equally to the SysV and systemd bootscripts packages. To get an Runit script running, all you have to do is create a symlink between the script work folder and the service folder, but there's very few existing scripts as little attention was ever given to Runit.

We need someone who's proficient in init scripting to draft at least an equivalent Runit script set for all daemons, runlevels, and such to create a full fledged script set for Runit.

I picked Runit because Garret Pepe created this software to target all of UNIX, not just one branch of the tree. Runit runs on MacOSX, Solaris, BSD, Linux, and several other flavors though only a few can officially boot with Runit for now.

We all know full well that if a project can be made to work with LFS it can translate to any Linux distribution.

I think ArchLinux had scripts in their AUR repository, we could check it out.

You have to view the question from a different angle: What is the point of having a Linux From Scratch with systemd?

Systemd ist basically the "kernel" of Lennart Poetterings "Core OS" and the reference implementation of "Core OS" is Red Hat Enterprise Linux 7. So by building an OS based on systemd you end up with a more or less mediocre ripoff of RHEL7.

What is the point of doing that?

Exactly.

If LFS is still using sysvinit by default, and all they needed was udev, they should have researched, at least in my opinion, another low-level alternative init system and stuck with eudev. Going systemd was just overkill and unnecessary.

I've been meddling with Runit for several months now, and I can actually say Runit is a viable alternative and the scripts from ArchLinux gave a better insight into the init system.

The problem is now is getting the exact needed LFS-Runit-bootscripts that duplicate LFS-bootscripts and then reduplicate the BLFS bootscripts to match.

Exactly, LFS really should not have anything like a default IMO, using systemd as a default for anything defeats the purpose of LFS in the first place

If they shouldn't have a default than it also shouldn't be sysvinit, they should have one book for any init system.
As I see it, and as is described on their website, LFS One may like it or not, but nowadays the majority of Linux systems run on systemd (or are planning to do so in the future), at least on the desktop. Mobile Linux devices will in the future most likely also run on systemd (Sailfish does now already, Ubuntu will do it and it is not unlikely that Google will follow and not stay with the abandoned upstart). Of course some desktop distros will resist to use systemd, and likely a whole bunch of distros/build systems aimed at the low-spec embedded market, but nonetheless, a LFS that ignores systemd will not anymore teach how most Linux systems work, it will limit itself to teach how a few desktop distros and embedded systems work.
Not having a default means that you should have at least the most popular options and describe them in the book, which would IMHO mean that at least sysvinit and systemd should be part of the book.
Naturally this is up to the developers and how many time they can (and want) to spend on implementing and testing this, but IMHO a LFS that does not handle systemd and sysvinit would be a loss to its goal to teach about Linux.
Keep in mind that I mean the init system, not the project, when I speak of systemd.

The major distributions shouldn't dictate the outcome if the foundation standards. SysVinit is still the base standard as is udev. Just because systemd swalowed udev whole, eudev is the base implementation of udev.

The focus of LFS is becoming less of a distribution and more of a guide book. To be honest there are efforts outside the norm to go without systemd and sysvinit and get a small yet modern system up with alternatives that uphold the UNIX philosophy.

Should the book ever fully go systemd, we are getting prepared. We doubt it, but best to be ready.

I don't see why systemd should be standardized just because it is used for udev. Udev is only a small part of systemd and using SysV alongside of systemd just because of udev is about as pointless as trying to reimplement DGA extensions in X11 just to get mouse pointer support.

If the focus of a distribution includes "teaching how a distro works" then leaving out systemd, which is used by the majority of distributions (or at least will be used by the majority once Debian and Ubuntu have switched) will diminish that focus, simple as that.
And yes, what the majority of distros use simply is "the standard", if you like that standard or offer alternatives is not relevant for that.

Yes, but ironically systemd takes away from administrative fundamentals so learning systemd is virtually learning nothing except something that isn't going to help you in the long run when systemd fails. There's no obvious point of using a system that takes away from administrators and education. Without knowing basic scripting an administrator is literally at the mercy of the system tools. Distributions like LFS really should be focusing on the point of the purpose of the book. Teaching the foundations and learning the core basics of administration.

Plus look at it this way, as I said it in my eudev hint, if LFS is focused still on using sysvinit as a baseline for controls of the system and only uses systemd for udev, why deploy all of systemd just for a small part of it? The worst part is by the next update of systemd, anything that might be useful could be usurped and changed out, so trying to find any semblance of stability with systemd is going to be nearly impossible.

Gnome is not even in the scope of the BLFS book as it is, and Gnome is the only reason most major distributions are switching to systemd anyway, not for udev functionality purposes. Only parts of Gnome are even utilized in the book for dependency resolution and extra tools for non-KDE desktop environments. Gnome is a popular desktop, but outside of major distributions, most people use Xfce, LXDE, and KDE still.

I just hope that by the next book release in the stable section, they just give systemd the axe, or move it to dev only.

At which point exactly is systemd hindering you to learn scripting? At which point is the init system systemd fundementally different from, for example, OpenRC and hinders you to learn to properly administer your system?
On most distributions systemd is the reality of administration, so why should LFS avoid it? As I said above, IMHO LFS should teach how to build systems based on sysvinit and systemd.
That is something you have to discuss with the LFS developers. Fact is that most distributions change to systemd, so avoiding systemd in LFS will reduce its usefulness in teaching how distros nowadays work. This will help nobody.
Sorry, I have problems to understand that sentence in this context. Are you still speaking about systemd, the init system, or have you switched to systemd, the project?
That is merely your opinion, unless you can show us evidence that supports that claim. I can't see Ubuntu changing to systemd just for Gnome, for example, neither will most Ubuntu or Debian derivates do it for Gnome, but because the base system, their standard, runs systemd. Gnome may be one factor, but I seriously doubt that it is the only factor.
And I guess you have numbers to back that claim up?
I hope they do not. I hope, if developer time allows it, that they teach sysvinit and systemd.

I'm not even going to try Tobi. You know what I'm always wrong and you're always right. Apparently I'm just a idiot. I'm through trying man. I'm done. Peace out and have a good topic bro. Enjoy.

I don't think you are an idiot. IMHO sometimes a little bit too zealous, but no idiot.
Anyways, it is the whole point of a discussion to bring up counterpoints and ask questions. If you don't want to do that then there is indeed no reason for you to participate, you are right with that.

It's not so much zealotry but trying to push the notion that the lack of using common sense that permeates a lot of daily life now has pushed it's way into the software world. Everyone with enough common sense could agree that having a single point of failure should have that single point of failure as small, insignificant, and least likely as possible should be a goal, not the opposite.

It actually does look like propping up Gnome Shell is the primary reason for this. We know that Gnome Shell needs systemd-logind which fails to function outside of systemd-as-the-running-init-system after version 205. It's no accident that Jessie currently uses version 204, and Ubuntu 12.04 shipped 204 for five years of LTS support. The systemd-shim packages, at least according to their descriptions, seem to hint at working toward using other parts of systemd even when it isn't used as the running init system. This seems to suggest that systemd won't necessarily be integrated to the extent that is done in Fedora and Arch (to name a few). Also installing a minimal/netinstall isn't likely to require systemd. As mentioned the metapackage sysvinit suggests the possibility to use one of three supported init systemd, at least for now. As Ubuntu has upstart they would thus have little interest in changing init systems had upstream not caved in, and even then it was just one or two people on some "technical committee" under questionable motives potentially influencing half of Linux users. So, yes, while these distributions may have chosen systemd, no, it is hardly a "majority" that supports this path or even considers it viable.

Perhaps one thing that the majority of distributions should remember is that "support" should not equal "requires." For example, the Mate devs seem to understand this quite well. Yes, Mate supports GTK3 and systemd, but that doesn't mean you HAVE to build it against GTK3 etc. But I think we can all easily see what's wrong with that picture - systemd flat out won't even let you "support" it unless used as the running init system, aka "required."

Mate took the right approach by using, if I'm not mistaken, the more universal choice of ConsoleKit which is the legacy support of logind. It allows, again, if I'm not mistaken build flags for both software sets, much akin to Xfce's approach.

And again I am puzzled if you speak about systemd the init system or systemd the project. Any init system, regardless if it is systemd, sysvinit, launchd or whatnot is a single point of failure.
Gnome Shell does not need systemd-logind, it needs the DBus services provided by systemd-logind. Anyone who really is interested in running Gnome Shell on systems where systemd-logind is not present can implement those services on their own. Gnome is no reason at all to go for systemd if you are not willing to use it. Just an example, some OpenBSD developers are totally willing to do that.

Its not just systemd init, its systemd in general. Systemd puts a huge load into PID1. The more stuff that runs in PID1, the higher a chance of failure you end up with overall if PID1 fails.

Think about a Hypervisor. If a hypervisor crashes, anything running on top of it goes crashing down too. Its one thing to also have stable software running in PID1 but to have software that's in continuous development cycles is haphazard.

If inetd crashes, all you have to do is restart inetd. If systemd-networkd crashes, you have to reboot.

One of the main reasons I began my work with Runit was because Runit has been long term stable. I can guess 6 months from now a possibility, but not likely service release update to Runit, but highly unlikely.

Its like a tree. The larger the trunk of that tree, the larger the point of failure, the smaller the trunk, the smaller the failure point.

While its always a SPOF, its the causes and excessiveness that causes the failures.

systemd-networkd is a daemon as any other daemon, you don't need to reboot, you can simply restart it (in fact, systemd will try to restart it itself if you tell it to do so).

ReaperX7, maybe you have seen this? Someone working on his own seems to have made an on an alternate init system for LFS. Other than this there doesn't seem to be anything else about it.

without-systemd.org
 

hrm, no one yet mentioned http://without-systemd.org/wiki/index.php/Main_Page in this thread? it may be an old thread, but websearches for what's bad about systemd still point here and it's still an important issue, so i thought this thread could do with this link, particularly for the two links in its homepage's first intro paragraph:

a lot of very worthwhile essential reading in there.
pertinent stuff.

( and in case without-systemd.org ever dies, there's https://web.archive.org/web/*/without-systemd.org )

I've pretty much walked away from GNU/Linux for the time being, but reading about the DynamicUser and other new issues, only seems to further the fact the octopus is still far from growing new legs, or the mindflayer is still trying to spread it's will and influence to the other realms. Progress be praised, security be damned, and sanity be lost.

The software had matured and more or less stabilized to a point of viability as being somewhat in the realms now of sanity, but the problem yet again of feature-creep has re-raised the tentacles. As it stands, debugging systemd is downright nearly a bad project with poor management. See here: https://utcc.utoronto.ca/~cks/space/...AndItsIdealism

The problem seems to persist, nobody at the project gives a damn what they fudge up, the distributions using it could care less to help you at all, and really speaking, so few alternatives exist. I actually attribute systemd to Goku Black and Zamasu.

Systemd is here to stay. I would have preferred a less controversial solution myself but, something was/is needed beyond classic init. There are many times systemd makes me just furious, but it is what it is. That said, I don't really spend any more time sorting out systemd issues than I did sorting problems with init scripts in the past. I also custom build the package and turn off stuff I don't need or want.

I found two really good videos about the problems with classic init systems a few months ago. One was an Apple presentation from 2008, explaining why they created launchd. Another one was more recent, from the creator of S6. There are all kinds of problems that exist today that didn't when init only started like 5 daemons on every UNIX system in existence. Basically, it comes down to needing an OS layer between root space and user space... the system space. SUID is a hack that shows its age with the modern internet.

The problem of init was system developers got lazy and wanted an easy way out of writing effective scripts. It wasn't about system management, relaunching failed daemons, or solidifying a control set, it was about laziness.

The arguments for systemd have never held water. The only reason why it was wanted was because the problem was created to ensure systend was to be used.

S6, runit, daemontools, perp, etc. all provided the exact same thing as systemd while leaving the outlying functions to other projects.

"Write one program that does one thing, and does it well" was the standard UNIX philosophy. Why? It created allowances for project responsibility. Ever heard the term "less is more"? It applies to this. Less code to deal with, means less chances of screwing it up, and more chances of getting it right.

Init was just that. Init. Init is not the supervisor, manager, login agent, session manager, kernel loader, etc. It's just a tiny program that boots the system, then forks itself to another instance(s), then reaps child processes and shuts down the system. You don't even need sysvinit to boot a system. All you really need is bash. Sysvinit just gave a small set of tools to make it simpler for scripting.

You want XYZ, add another program and learn to write the scripts to use it. If all Linux needed was a system state manager for keeping daemons alive, we had it for years and never used it over pettiness and stupidity. Daemontools has been around since the late 1990s and did the work systemd promises. Why 10-20 years later reinvent the wheel for nothing? Ask lazy system developers who can't write simple bash shell scripts. Red Hat wanted to be the next Microsoft for years now. This just let them make Linux into their own clone of Windows.

80 years ago... "Hand crank starters work fine. I don't need none of this new fangled electronic ignition stuff. Just adds complication to the car. Need a bigger battery, bigger cables, and one of those silonode thingamajigs. No thank you, my arm is good enough."

30 years ago... "I've got no use for this fuel injection stuff. My carburetor works fine! This fuel injection requires all kinds of new complicated stuff. Pump in the fuel tank, high pressure lines, wires and sensors everywhere and a computer! Now, who the hell needs a computer in a car. All just a buncha nonsense is what I say... Keep it simple... that's what I say."

Things change. No one can avoid it forever. Personally, I think systemd was the worst of the choices available. That said, so many have jumped on it is hard to avoid so I decided to go ahead an learn to live with it. I've almost dumped it a couple of times, but then I didn't want to back and update 2 dozen init scripts I archived 3 years ago. Perhaps we'll get lucky and something smaller will be introduced and takeoff, replacing both systemd and systemV.

Smaller is relative. The issue should be having a project that holds itself accountable for problems, addresses them in a timely fashion, and keeps sanity in coding practices like documentation, debugging, etc.