Hi,
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.
So, I guess here are the points
---------------------------
Apparent Simplicity
---------------------------
Init scripts had text files while systemd will have binary files
to load from. So, there is a point of error in converting the .conf to
binary files and I guess, this worries users because, even if they do not
know it, they are fearing that the text-to-binary conversion will not be
proper (due to various reasons such as some user accidentally editing a
file with gedit and setting different encoding and thousands of other
reasons) and hence, will end up borking the system.
Now I am not sure, since I have not actually used systemd, about
how much this point is correct, since it depends a lot on the design of
the systemd parser and how the output is, but I would like the following
features for the same:
1. Systemd should overwrite the current binary files if and only if it
can verify that the new files are correct. So, it can do something like
regenerate the text from the binary and then check with the original
text or some as the user if the information is correct.
2. Systemd should have a mechanism by which it can fallback to reading
the text files and booting from it. I do not know if this feature is
really useful since init scripts already do this and hence, you can make
it fall back on initscripts instead, but the point is then I would then
have to maintain two systems, one which I use regularly (systemd) and
one which I do not, and when systemd fail, I would have to use the
initscripts which I do not use regularly and hence is a big error-prone
exercise. Hence, if the users can have that guarantee (which I think
there is) that the systemd configuration files can be used by initscripts
to boot an exact system (though slower then I guess) they will be
satisfied.
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.
-----------------------------------
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.
----------------
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.
Thanks for reading such a long mail if you have reached this far!
--
Cheers
Jayesh Badwaik
stop html mail | always bottom-post
www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
