On Thu, Dec 27, 2012 at 10:29 AM, Kevin Chadwick <ma1l1i...@yahoo.co.uk> wrote: >> * Finally, and what I think is the most fundamental difference between >> systemd and almost any other init system: The service unit files in >> systemd are *declarative*; you tell the daemon *what* to do, not *how* >> to do it. If the service files are shell scripts (like in >> OpenRC/SysV), everything can spiral out of control really easily. And >> it usually does (again, look at sshd; and that one is actully nicely >> written, there are all kind of monsters out there abusing the power >> that shell gives you). >> > >> Then Kevin started to suggest that I know nothing about init systems, >> and I responded in kind. > > I did not and apologise if you took offense.
Apology accepted, and I also apologise if my response was out of line/with bad tone. > I said perhaps badly that > based on this posting, you don't have a great deal of experience in > init systems. Well, I haven't wrote any, but I used the ones in OpenBSD, Solaris, Linux SysV, OpenRC systemd, and Windows NT. Used as in administering several machines with them. So, I have some experience. > To me, your comment demonstrated that you don't on the > vast plethora of init systems which all actually accomplish the same > thing daemon wise just with varying reliability and functionality > surrounding the process of doing so. No init system can tell a daemon > how to do anything. You are wrong. In SysV, I can *write* the daemon in the init script. In *that* sense, the init system tells the daemon how to do things, and to a lesser degree, it happens when you use a shell to launch daemons. > So your comment. > > What to do, how to do actually has nothing to do with systemd. > > What does is having to learn a new more restrictive non > intuitive and non externally useful or non universal *declarative* > language. Like polkit/pkexecs javascript vs sudo. I will take sudoers > every time and for good reason. I'm not 100% happy with Polkit use of JS, but having finally understood how it works, I think is kind of nice. I believe role verification and authentication is one of the tasks where a Turing-complete language actually be justified. > "Shell scripts usually spiral out of control" is just utter FUD. I > do realise you didn't originate this FUD, but it shouldn't be > spread. Yes some corner case wants in init that some thought > impossible in shell can get complex by scripting them but a small c > tool following the unix philosophy simply becomes a shell command > potentially useful in even unforeseeable cases. Funny that you said that; if you are really interested, take a look at /usr/lib/systemd in a systemd machine. Almost all of those are really simple C programs that do one thing, and one thing only. Most of them don't reach the 100 lines of C code. To me, a Turing-complete language for starting and stoping services is overkill. And also there is the Halting Problem; you simply cannot workaround that. > We are dealing with simple options meant for admins here. As I said > OpenBSDs scripts are usually rediculously simple and should often > really be called commands. As others have said the argument of function > being in the scripts rather than the daemon is an irrelevance to using > systemd. Systemd may try to become the whole OS but I'm fairly sure it > hasn't plagiarised the c code to check and deal with ssh keys yet. That > is rightly the job of the aptly named ssh-keygen and IMO some very > simple shell code. Yeah, running from the install script/Makefile/post-inst-hook/whatever. Not the init system. IMO. > The arch sshd script is only 44 lines and includes more than that to > make the output colourful. The gentoo sshd script is actually simple > too and doesn't do anything most of the time and is easily modifiable > in absolutely predictable ways. I'm not arguing that; I'm arguing that it can be done even more simple, and even more easily modifiable. But like a said to Pandou; let's just agree to disagree. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
