Laurent Bercot <ska-devel@???> wrote:

> On 25/09/2015 09:05, Simon Hobson wrote:
>> More to the point, I'd rather have reliability over speed any day.
>
> How about you get both?

Well yes, that's better still.

> The dichotomy is a false one. People believe they can't have both
> because init systems have never been done right so far, and always
> forced them to choose between one and the other. This is what
> I'm aiming to change. No less.

Well yes. I tend to be happy to stick with sysv-init because a) I know how it works, and b) it's easy enough to diagnose issues, and c) it's "good enough" for my needs. Yeah, it's not perfect, but *for my needs* I can easily work around those imperfections.

What you are doing does sound good, guess I should really add it to my list of stuff I'll probably not find time to look into :-(

>> But one trick that the desktop vendors are doing, and I suspect
>> SystemD are copying, is to "fake" a fast boot. By prioritising
>> certain bits, you get the illusion of a fast boot
>
> Yes. I have no idea how Windows does it, or how other OSes do it,

Windows and MacOS both prioritise those tasks needed to get a desktop picture (or login prompt) on the screen - as that gives the illusion of fast boot time. That the system is still far from ready is evidenced by a) the time it takes to load all the applications I am usually running, and b) the disk and CPU activity going on for quite a while afterwards.
IME the fast boot is largely illusionary anyway - the disk I/O and CPU utilisation makes the whole system "sluggish" so it's not worth trying to do anything until all the background stuff is at least well past it's peak !



Rainer Weikusat <rainerweikusat@???> wrote:

>> * anything that uses the syslog should start after the syslog.
>
> That's the same misunderstanding already shown elsewhere: Starting
> syslog at time X and starting syslog-user at time Y, Y > X, Y - X being
> 'very small', does not guarantee syslog will already be available at
> time Y and neither that it will still be available provided it became
> available in the time interval between X and Y.

That all hinges around what is meant by "start service A". If "start service" means nothing more than "kick off a process that'll run it" then you are completely correct. On the other hand, if "start service" actually means a process which is only deemed to be complete when it's running and ready to go to work then that's a different matter.

Of course, regardless of what system or definitions you use - if a service then dies then you have a problem. IMO, "it might die at some indeterminate time" isn't an excuse for not trying to get the "start stuff up" part right. Taking the example of syslog - if it dies (regardless of when, whether it's seconds or days after system start) then you are going to lose logging. You can try and manage that (spot the problem and deal with it automatically), but short of predicting the failure in advance, there will always be a window during which logging can be lost.