Jaromil <jaromil@???> writes:
> congrats to the on-time release Laurent!
>
> dear Katolaz and others
>
> On Thu, 24 Sep 2015, KatolaZ wrote:
>
>> On Thu, Sep 24, 2015 at 07:20:25PM +0200, Laurent Bercot wrote:
>> > On 24/09/2015 17:51, Rainer Weikusat wrote:
>> > >If it starts working within less than five minutes, users will
>> > >forget about it faster than they could complain, especially for a
>> > >system which is usually supposed to be running. But that's actually
>> > >a digression.
>> >
>> > Five minutes? And you think it's acceptable? Sorry, I don't have
>> > five minutes to waste every time a program fails. Also, this is
>> > 2015: if a program isn't responsive within 30 seconds, users will
>> > come knocking at your door raging - and they will be right.
>>
>> But let's be honest here: how many times does it happen that you have
>> to reboot a production server nowadays?
>
> I think you are overlooking the vastity of use-cases here and I agree
> with Laurent for a 5 minutes down you can have users raging at the
> door.
>
> for instance I can well imagine we may end up using s6-rc for
> http://dowse.equipment which isn't a server, but a home network
> appliance that filters a lot of traffic (adblocking and such), caches
> and tunnels DNS queries etc.
>
> Now if any of the daemons running on Dowse go down then the "Internet is
> broken" for any inhabitant on that LAN and that is the moment in which
> you get any other member of the household to knock the sysadmin's door -
> reaction times are below 1m in my experience.

Well, but this wasn't about "daemons going down", it was about "faster
availability after a system start" claimed to be achievable by starting
services in a certain order, eg, (the only services which was actually
named) start a recursive resolver before any application which could
want to resolve DNS names, as opposed to "start everything in no defined
order" and accept that there might be a (short) time window where some
application already wants to use DNS but the DNS server/ resolver isn't
yet ready to handle this request.

This time window is going to be a lot less than "5 minutes" (presumably,
it's going to be a lot less then 30s) and I had a particular deployment
scenario in mind where certainly no one will even be able to get hold of
"an IT support guy" within five minutes even assuming he'd be trying
(instead of rebooting his iSomething a couple of times as that "helped
in the past). This particular deployment scenario is not universal but
neither is "family members come a knocking within less than a minute".