On Mon, Aug 4, 2014 at 10:37 AM, Andrew McGlashan <andrew.mcglas...@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.mcglas...@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. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOdo=szepe6tacv76nlfh4zvzcrna3zum58hxx1b_qgzyo7...@mail.gmail.com
