[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: End of hypocrisy ?



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"?


>>> 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.

I also once read an article that claimed that Google had said that
every reboot costs it money. I googled for it but nothing came up.


Reply to: