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

[Canek Peláez Valdés]

On Fri, Dec 28, 2012 at 5:23 PM, Kevin Chadwick <ma1l1ists@××××××××.uk> wrote:
> On Fri, 28 Dec 2012 13:14:46 -0600
> Canek Peláez Valdés <caneko@×××××.com> wrote:
>
>> On Fri, Dec 28, 2012 at 12:53 PM, Kevin Chadwick
>> <ma1l1ists@××××××××.uk> wrote:
>> > On Thu, 27 Dec 2012 17:38:15 -0600
>> > Canek Peláez Valdés <caneko@×××××.com> wrote:
>> >
>> >> In SysV, I can *write* the daemon in the init script.
>> >> In *that* sense, the init system tells the daemon how to do things,
>> >
>> > Please explain, sure there is the environment that tells a daemon
>> > what to do. No shell can tell a c daemon like sshd how to drop
>> > priviledges or use systrace but it could do these things for it in
>> > a more fine grained manner before it tries and fails itself or if
>> > the daemon wishes it to like monit. It's still not telling how but
>> > duplicating or removing the need. That's just a bonus that applies
>> > to all init systems because shell is so powerful on unix.
>>
>> Stop thinking in sshd. I can write the *whole* daemon in shell, not in
>> another script file, but inside /etc/init.d/mystupiddaemon (or
>> /etc/rc.whatever); shell is Turing-complete, I can write in it
>> anything I can write in C (or in assembler, or machine code). In that
>> sense, the init system (which uses shell for launching daemons) can be
>> used to determine *how* the daemon behaves (because it uses shell for
>> launching daemons).
>>
>
> That's what you meant, how disappointing. Yeah I've knocked up a few
> very useful ones myself but call them scripts (Such as grepping logs or
> dns servers and feeding real daemons with info).
>
>> You can't do that with systemd; there is a clear and unavoidable
>
> You can't is better is it? Yet you can exec a daemon written in shell
> with systemd.
>
>> separation between the starting/stoping/monitoring of daemons, and the
>> daemons themselves.
>
>> Such distinction doesn't really exists in SysV nor
>> OpenRC (since they use shell, a Turing-complete language, for
>
> With regular expressions to get the exact pid but
>
> /usr/sbin/sshd -f /etc/ssh/sshd_config = start
> /usr/bin/pkill sshd = stop or many other incantations
>
> There are many tools that do this job just fine. If systemd just did
> this and was there by default I would consider replacing monit with it.
> Like a reliable root filesystem I want a reliable pid 1.
>
>> launching daemons), and therefore you can mixup everything. I agree,
>> it doesn't necessarily means that it *will* happen; but even the
>> possibility is frigthning for a system administrator in a production
>> server. With systemd, that possibility *doesn't exist* (because it
>> doesn't uses a Turing-complete language to start/stop/monitor
>> daemons).
>
> Doesn't frighten me one bit. I know the startup almost inside out of my
> servers, doesn't take long on OpenBSD. On Linux it would take longer but
> nowhere near reviewing systemd and knowing C has nothing to do with the
> immediate control shell can provide under any init system including
> systemd but the Turing complete argument is simply propaganda as well
> as all the features to distract from the fundamental flaws in the
> design of systemd.
>
>>
>> Like the clear separation between content and presentation in webapps,
>> or between the model and the view in the MVC design patter, having a
>> clear separation between how you start/stop/monitor your daemon, and
>> what the daemon does, is a good thing. If you don't agree with that,
>> well, we must agree to disagree.
>
> There is nothing else, you exec or parse a script or daemon just as
> systemd does. The only difference is systemd tracking double forked
> processes with cgroups and I have already provided a link that refutes
> any point to do so. There are corner cases that are easily manageable
> and it certainly isn't worth the sacrifice of POSIX compatibility and
> so Linux applicability. Linus has said cgroups are a horrible
> but necessary evil, which in my opinion means avoid them unless you have
> no choice. There is a perfectly good and in my opinion superior
> choice, but I love simplicity, it has served me well.

I don't doub it. As I said, the only thing to do is to 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