And why some distros like MX don’t want it?
Here is a tutorial that may help. Systemd is complicated to explain, I think the main reason it was so poorly received was the way Debian chose to implement it without any consensus among it’s developers. That was one reason. It’s a more complicated system and some think too complicated for boot manager. And it actually does control a lot of stuff in the system.
MX does have systemd available and it can be installed in MX they have chosen for now to keep system V as the default. If you run a Distro with Gnome 3 I think you pretty much have to run systemd for some things to work for you. Although some have reconfigured things so they work with system V init. Here is a list of systemd free Linux Distros. You will notice that not many of them use gnome desktop.
In any event personally I don’t really care as long as the system boots and work well on my hardware. systemd works good for me.
But both these sites would be a good reference point.
I use some of the available systemd commands, ie computer to boot up time seen below.
mack@desktop ~]$ systemd-analyze time Startup finished in 7.284s (firmware) + 1.716s (loader) + 5.894s (kernel) + 1.655s (userspace) = 16.551s graphical.target reached after 1.213s in userspace
In reference to MX Linux shim usage, quote from their manual.
MX Linux uses sytemd-shim, which emulates the systemd functions that are required to run the helpers without actually using the init service. This means that SvsVint remains the default init yet MX Linux can use Debian packages that have systemd dependencies such as CUPS and Network Manager. This approach also allows the user to retain the ability to his/her preferred init at boot by clicking on"Advanced options" and selecting the systemd one. We can not provide support for users who choose to run MX Linux using systemd.
Edit 26/02/19 1936hrs typo
So it’s not related to system issues that would make things faster/slower or more/less resource hungry?
Actually it was originally touted as allowing faster boot times. But it’s a fine line and often systemd boots slower than system V. Just a non scientific observation. Only issue I’ve seen with it is that some people don’t want any change in the way things were done, and others don’t like the invasive nature of systemd to control functions that don’t really have to do with the boot sequence. It’s more complicated to manage but also offers more output when problems do appear. Most system managers I’ve talked to like it better than system V. here are a couple more linksDebian and Arch in case you want to do more study. And here is one on the comparison between the two systems.
Thanks to you both for offering this “full course meal” on systemd !
@danielson Before I edit your thread, I wanted to say that when you created it that was fine. However when I looked at your first post I wasn’t sure what it was about as some others might be. Perhaps you could also put the question in the post as well to clear that up. ( Thank you)
Great question and I am glad you asked it as I am sure many of us have wondered it and good to see @mack and @kc1di have given, as you have said a “full course meal”.
If the question is now answered can you now mark it as being so on the answer that was given. Again that would help the community to do understand that it has been done. If you are unsure of how to do so please ask and some one will help you
@danielson, i don’t know much more that what has been presented here, but this is what has been said in some of the subreddits that i follow. basically those responses feel more philosophical than practical. they say a core linux principle (my paraphrase) is that each system process should do one thing and do it well. their general complaint is that systemd has its fingers in too many other areas.
Yep, the Debian civil war, mass exodus, and the birth of Devuan.
I was trying to make sense of the original system, when systemd reared its ugly head. Nonplussed as this subject still had an opaque veil I couldn’t see through, then the penny dropped and slowly gasped some of the logic to edit files, to enable or disable services safely.