On 18/04/2017 at 16:16, KatolaZ wrote:
> On Tue, Apr 18, 2017 at 02:48:54PM +0100, Arnt Gulbrandsen wrote:
>> katolaz@??? writes:
>>> Unfortunately we are already paying the consequences of badly-written
>>> software implementing oddly-designed solutions to non-existing
>>> problems...
>> Indeed. But what's your point?
>>
> Oh, you are right, I didn't make it explicit: my humble opinion is
> that the whole thread is not particularly interesting or useful in
> this context, since all this fuss about monitoring/supervision boils
> down to two alternative options:
>
> a) you *really* need *strict* monitoring/supervsion. In this case,
> you *don't* use a unix-like operating system, since you are always
> left at least with the problem of monitoring the monitor (or
> supervising the supervisor). But this is not a real problem, since
> in those environments where *strict* supervision/monitoring is
> *really* necessary, unix-like systems are rarely used, if ever, and
> the scheduler also acts as a monitor/supervisor. So if you need
> *real* *strict* monitoring, the whole topic is off-topic here.

I do not agree, as Linux systems are employed both in real-time
scenarios (though I admit this is a really niche use case) and in High
Availability infrastructures.

> b) you need *loose* monitoring/supervision. In this case, you pick
> and choose among what is available, or write your own. In any case,
> you get a monitor/supervisor running as a user process on top of any
> general-purpose operating system, possibly a unix-like one, and your
> applications must still be able to deal with faults,
> inconsistencies, delays, and other issues. And sometimes you will
> still need manual intervention nonetheless. The "everything will be
> all right" theme is just dust in your eyes, because things are never
> going to be all right all the time.

This is an argument that sounds as an excuse to me: "Since you'll
never get perfection, just do nothing." Everyone knows that even top500
supercomputers do need some manual intervention from time to time. This
is not a good reason to put the sysadmin in charge of manually managing
all the processes and events that they produce. Some OS could go this
way, of course, free to. But you know very well that such an OS, though
philosophically and academically fine and technically elegantly
constructed, is not going to win any significant market share, as today
everywhere the utmost of automation is a prime requirement.

> There is really no other reasonable alternative, IMVHO.

Yes, there is. It's called a good compromise. Then, outside of it,
you find the purists and the extremists.


Alessandro