[arch-general] Systemd : Analysis of reactions of Users

[Jayesh Badwaik]

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