Re: End of hypocrisy ?
Le 04/08/2014 21:34, Tom H a écrit :
> On Mon, Aug 4, 2014 at 10:37 AM, Andrew McGlashan
> <andrew.mcglashan@affinityvision.com.au> wrote:
>> On 4/08/2014 11:32 PM, Tom H wrote:
>>> On Mon, Aug 4, 2014 at 6:37 AM, Andrew McGlashan
>>> <andrew.mcglashan@affinityvision.com.au> wrote:
>
>>>> My own view is "why systemd" .... fix sysinit instead, where it is
>>>> broken or rather the packages [whatever they are] that don't work properly.
>>> Who should fix sysvinit? The upstream sysvinit developers are DDs and
>>> they didn't do it (I'm not blaming them, I'm just noting that fact).
>> Yes, that's what I meant, sysvinit is not broken.
> Some people'll disagree with the above statement. For example, if you
> stop a sysvinit daemon, you cannot be sure that all of its children
> will stop too whereas you can be with systemd.
>
> Going back to "fix sysinit instead" (which is what I was replying to),
> did anyone add cgroup support to sysvinit so someone could tell
> Lennart "f-u, sysvinit can kill double-forked children"?
>
For me that should be the responsibility of the service itself.Not of
the init system.
>>>> systemd gives faster boot times, so what! I prefer to boot less often
>>>> and run with what works until I /have/ to do a reboot, so it wouldn't
>>>> matter if it took 10 times as long to boot. Improving boot times is
>>>> just like overclocking for games, it is largely irrelevant and something
>>>> to boast about ... ie, no real benefit.
>>> Boot speed might not be an important feature for you but for
>>> organizations with 1000s of servers, the faster the better.
>> Sure it counts, but if you have 1000s of servers, you likely have many
>> other considerations and you'll be pooling [at least] those servers in a
>> cluster type arrangement ... much lessening the need for any machine to
>> startup so quickly.
> It's a nice theory. I'll give you an example (not fully technical but
> an example nonetheless; and I could give you others.
>
> Suppose that you have a 16-node cluster, some patches were applied to
> the systems overnight, a mistake was made, and you have to correct
> this mistake on all of the systems during trading hours. Once you get
> all the OKs that are needed for this kind of emergency change, the
> head of the trading desk that uses that cluster calls you and says
> "I'm going to be on the line for as long as you're working on our
> system." So you fix one node, reboot it, make sure that it's back in
> the cluster and doing its job, and fix another, etc. You can be sure
> that everyone's happier that the systems boot quickly and that the
> cluster was running with 15 rather than 16 nodes for as few minutes as
> possible (because you can be sure that the fact that this cluster
> wasn't running at full capacity for X minutes will come up in
> managerial meetings, both in IT ones and in IT-Business ones).
>
> I don't care what's bringing up a system,
> sysvinit/systemd/smf/launchd, the faster the better.
What takes most time when booting a server is what the server does
before booting the OS (before grub in case of linux). Optimising what
comes after is non-sense.
Note that with systemd more upgrades will necessitate a reboot, since
systemd does many things...
Reply to: