"Garry T. Williams" <gtwilliams@xxxxxxxxx> writes: > On 7-6-14 10:39:11 lee wrote: >> "Garry T. Williams" <gtwilliams@xxxxxxxxx> writes: >> > The analogy is placing a script in /etc/init.d and then linking >> > its name in the /etc/rc5.d directory. >> > >> > I find this much simpler than the sysvinit schemes. >> >> You have taken well over 100 lines to give a description about how >> to get a daemon started with systemd, not to mention the hours you >> must have spent reading all the documentation to figure out how to >> do what you wanted. > > Of course, my message was an attempt to explain what a Unit is to > Patrick. The bulk of my reply was not describing how to get a daemon > started with systemd. That shows the problem: Systemd attempts to replace something which is simple and straightforward and does work with something that is anything but simple or straightforward, doesn't work and involves a dozen types of entities which are neither evident nor structured. > As to the hours of reading, well, yes. systemd was new when I first > encountered it. How else could I learn how it works without actually > reading the documentation? When I want to do a simple thing like starting a daemon, I don't want to learn how systemd works but get the job done. >> It took you only 2 lines to describe how to do the same thing with >> sysvinit. > > Yes. > > But have you looked at the sysvinit script to compare it to the > Service unit that accomplishes the same thing? I can read the script but not the entity. > The point is that there is lots of boilerplate in every sysvinit > script to do the simplest task. That makes it easy to copy an existing script and to adjust the copy to your needs. > The systemd Service unit corresponding to the abrt init script is way > simpler. And it can accomplish stuff the bare script cannot, like > automatic restart upon failure. Look at the script to start chronyd Debian uses and the entity Fedora uses for the same thing. The script does more than the entity does, and it tells me directly what it does while the entity doesn't tell me at all. I don't know if the entity can do what the script does. Which real problem does systemd actually solve? There is no real need to start things in parallel (I don't even like it because I can't see the messages anymore because they are displayed too fast to read and show up even after the login promt is displayed). There is no real need --- even no point --- to restart something in case it fails because when something fails, merely restarting it doesn't fix the problem and I'd rather have it failed so that I'll notice and can fix it. There is no problem with copying common content from one script to another. >> I don't understand how you can find systemd "much simpler" than >> sysvinit. Where and how is it simpler than sysvinit? It takes only >> about 2% of the effort, if that much, to start a daemon with >> sysvinit than it takes to do the same with systemd. >> >> For systemd, you even have to learn a whole new "programming >> language" to create configuration files which is useless anywhere >> else. Efficiency is negative here. > > Reading the documentation, I know that the unit files do not contain > *any* "programming language". They are declarative. What is better about inventing a new language nobody knows compared to using an existing one lots of ppl already know? > That was very intensional in systemd's design. That was a bad decision. Why shouldn't I be allowed to make an entity I create do something? > Indeed, there have been many discussions and patches submitted to add > that very thing to the unit files on the systemd development mailing > list. These have been uniformly rejected because of this basic > design. Which very thing? > Yes, you do have to read and understand the documentation to > successfully use systemd. I'll leave it to others to comment on the > usefulness of a Unit file outside of Fedora. Debian and centos use sysvinit; I don't know what others use. -- Fedora release 20 (Heisenbug) -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
