On Thu, Jul 26, 2012 at 10:30 AM, Jayesh Badwaik <jayesh.badwaik90@xxxxxxxxx> wrote: > DISCLAIMER: I support systemd but haven't switched to it yet, because I > haven't had time till now, and also because I have some concerns. I like > the ease-of-use that systems like PA/Systemd brings but I sincerely > appreciate issues like the ones Ralf Mardorf and others have and I > sincerely hope there are ways to address their problems well. > > I have been reading a lot about systemd discussions everywhere, on > Fedora, on Arch and everywhere and I guess while the developers have > been clear about why they would like to switch to systemd, the users > have not been clear > > 1. Many times in discussions, some valid points by the user have been > covered with a "resistance to change" flavor and hence, led to a rebuttal > that has not addressed the valid point hidden within. > > 2. Also, developers work as a team while the users are scattered and > hence, every user tries to make a point which is essentially similar to > others and hence, gets a same rebuttal but the actual reason he posted > the question was because he wanted to know something which was not > clarified due to point 1. > > 3. However more failproof the new system might be, whenever you are > shipping it on such a large scale, the guarantee that the users want is > for the system to fail nicely. It doesn't matter to me if the systemd > has less bugs than the init code, if I encounter that 1 bug, I want have > a reasonable guarantee to get around it, and this is what is scaring > most of the users I guess. The above probably has a lot of truth to it :-) > --------------------------- > Apparent Simplicity > --------------------------- > Init scripts had text files while systemd will have binary files > to load from. This is incorrect. Initscripts use bash scripts, systemd uses .ini-like text files. > and hence, when people say that if systemd fails or you don't like it, > just switch back to initscripts, they are not addressing the real > concern of the users. Even though your premise was wrong, there is a point that it should be possible to switch back and forth between systemd and initscripts easily. This is the case. If you just install "systemd" and keep the "initscripts" package on your system, then in order to start from systemd just append "init=/bin/systemd" to your kerenl commandline to try it out. systemd will not write anything to your disk by default, so this is completely safe. If you don't like what you get, or there is a problem, simply reboot and remove the init= parameter and you get back initscripts. If ever you decide you don't want initscripts any more, then install systemd-sysvcompat which will make /sbin/init point to systemd, and remove initscripts and sysvinit from your system. > ----------------------------------- > Single File vs Multiple File > ------------------------------------ > Most of the users will access their rc.conf files once in a month or so > once their system has been setup considerably. I on my personal laptop > nowadays only look at rc.conf when there is a pacnew notification. For > these users, till now rc.conf was the one-stop service so to say. This > concept for them is similar to the one-desk customer service that banks > provide where you can get almost all types of manipulations to your > accounts at a single desk. This fact is very comforting. > > Point is at one glance, you can get all you want to know about the > system. This is especially true in case of daemons, now with separate > service files, you have to look in every service file to check if the files > are correct. > > If there was a single command to print out all the boot info, then > probably it would be great, but I guess this tool would be the same one > that I described in point 1 in Apparent Simplicity. Then, after every > edit and regenerate, I can test my files and satisfy myself that what I > have typed is correct. Systemd configures what daemons to start by creating symlinks under /etc/systemd/system. However, "systemctl" gives a nice interface for the user to see what the status is without having to read the symlinks. Have a look at its manpage for details. It is similar (but much more powerful) than our /usr/bin/rc.d. > ---------------- > DAEMONS > ---------------- > With respect to daemons, the BEFORE and AFTER in the service files is > redundant and though not likely to cause errors, likely to be > inconsistent, because for every service file where a daemon "xyz" appears > in AFTER, the corresponding daemon must appear in BEFORE in the service > file for xyz. I am not quiet sure why this redundancy is there, you can > simply have just "AFTER" variables and they should take care of all the > dependencies I guess. This is not true. You only need to specify either Before= or After=, not both. The reason that both exist, is that you should have the choice of which .service file to add the dependency. Cheers, Tom
