Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?

[Canek Peláez Valdés]

On Thu, Dec 27, 2012 at 10:29 AM, Kevin Chadwick <ma1l1ists@××××××××.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