[arch-general] Lennart Poettering on udev-systemd

[Anthony ''Ishpeck'' Tedjamulia]

On Tue, Aug 14, 2012 at 09:08:36AM -0400, Baho Utot wrote:
> What is so wrong with the booting using sysvinit?
 
As a critic of systemd, perhaps I can help.

Init scripts tend to wreck the determinism beacuse they can inherit
your env.  pid files are a problem waiting to happen.  There really
is nothing preventing them from getting trampled or deleted and 
then you've gotta go kill daemon processes by hand.

Having to start daemons in a certain order is obnoxious.

The more shell script you have to write in order to get daemons up
(or shut 'em down) just means more opportunity for little annoying
bugs.

Startup speed is therefore affected.  This doesn't matter if you
don't reboot often but if you're doing lots of systems dev, it can
be said that every minute spent waiting for the system to boot is
one less minute spent improving your software.

> I really don't need what systemd offers and sysvinit does everything I 
> need and has not failed me.
 
Indeed, this is a values judgment.  The argument for abandoning
init scripts could be made in the department of "Code
Correctness" as it is defined in the Arch Way...

https://wiki.archlinux.org/index.php/The_Arch_Way

There is no doubt that the community-tested traditions have
found their way into effectiveness.  

> As for systemd being better solution for the problem of booting the 
> beauty is in the eye of the beholder and I just don't see it, so why 
> take away sysvint?
 
I'm still experimenting with daemontools under sysvinit as I
described here:

https://bbs.archlinux.org/viewtopic.php?id=141831

The transition seems less brutal, the ability to start things
in parallel is there, supervision is there, but there is no
process grouping (which I consider unimportant) as with systemd.

> You can use systemd and I should be able to use what works for me and 
> not be forced down the systemd path.
 
As explained in this and other threads, it may not be a decision
we, in the Arch world, get to make.  Too much of upstream may
actually be dictated by what a comercially-backed distro does.