На: Lockheed-Martin испытал ракету-невидимку

Stanislav Latishko написал(а) к \"Andrey Platonov\" в Jun 06 09:31:08 по местному времени:

Tue, 30 May 06 17:56:47 +0400 Andrey Platonov (AP) писАл[а] :

AP> Можно предусмотреть ТАКУЮ ситуацию на будущее. Но продвинутый раззява создаст
AP> еще десяток подобных ситуаций. Будет бег по кругу, вырваться из которого можно
AP> только нормальной организацией летной работы вообще и повышением уровня
AP> подготовки экипажей в частности.

Есть еще один аспект проблемы, о котором сторонники автоматизации
всего совершенно не думают: чем выше надежность системы, чем реже она дает
сбои, тем сильней "расслабляется" человек, тем ниже его готовность перехва-
тить управление у свихнувшегося автомата. И когда случается очередная авария
потому что человек просто не успел понять что автомат отказал, это повод
опять говорить о том что человек ненадежен, что его надо вообще отстранить
от управления. Процесс с положительной обратной связью.
--
Stanislav Latishko

@@ sl @ sl . spb . su ; 2:5030/949 @@
--- ifmail v.2.14

Михаил Жук написал(а) к Stanislav Latishko в Jun 06 13:28:24 по местному времени:

From: Михаил Жук <m_zhuk@step.ru>

Stanislav Latishko пишет:

Привет, Станислав !

SL> Tue, 30 May 06 17:56:47 +0400 Andrey Platonov (AP) писАл[а] :

AP>> Можно предусмотреть ТАКУЮ ситуацию на будущее. Но продвинутый
раззява
AP>> создаст
AP>> еще десяток подобных ситуаций. Будет бег по кругу, вырваться из
которого
AP>> можно
AP>> только нормальной организацией летной работы вообще и повышением
уровня
AP>> подготовки экипажей в частности.

SL> Есть еще один аспект проблемы, о котором сторонники
автоматизации
SL> всего совершенно не думают: чем выше надежность системы, чем реже
она дает
SL> сбои, тем сильней "расслабляется" человек, тем ниже его готовность
перехва-
SL> тить управление у свихнувшегося автомата. И когда случается
очередная авария
SL> потому что человек просто не успел понять что автомат отказал, это
повод
SL> опять говорить о том что человек ненадежен, что его надо вообще
отстранить
SL> от управления. Процесс с положительной обратной связью.

Это ты зря - очень даже думают. Тема "скрипач не нужен" в эхе поднима-
лась неоднократно, эта ее сторона не единожды обсуждался именно для
эхотажных аспектов проблемы "человек и машина в едином контуре управле-
ния". Дело в том, что проблема настолько сложная, что, по моему мнению,
даже какие-то основные опорные точки для ее решения не очень-то намети-
лись по сию пору.

--
С уважением,
Михаил Жук
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5.3

Stanislav Latishko написал(а) к Valentin Davydov в Jun 06 10:20:22 по местному времени:

Tue, 30 May 06 06:43:28 +0400 Valentin Davydov (VD) писАл[а] :

VD> Критика тут тоже психологиеского характера. Программисты, нацеленные на
VD> создание работающей системы, часто не знают, что делать в случае, когда
VD> что-то не работает (exception handling на ихнем жаргоне). То есть даже
VD> если принудительно заставить программиста проверять на нуль перед
VD> делением, при попадании-таки нуля в знаменатель максимум, что сможет
VD> сделать программист - вывести диагностическое сообщение и отправить
VD> систему в перезагрузку. Что, собственно, и было продемонстрировано
VD> в своё время Арианом-5.

Ты несколько упрощаешь.

Расскажу для начала маленькую байку из собственной жизни :) Байка
не для этой эхи, но чертовски философски-поучительная :), а народ все-таки
б-менее компьютерно-грамотный, поймет :) Итак, дано: лохматый год, ЕС ЭВМ.
Машина наглухо виснет при неготовности АЦПУ. Раскручиваю причину и тихо
офигеваю... Неготовность АЦПУ рассматривается ОС как ситуация "сбой обору-
дования" и обрабатывается одной из программ обработки машинных ошибок,
расположенной в специальной библиотеке. На диске, перед блоком, содержащим
данную конкретную программу имеется ошибка вида "отсутствие адресного маркера".
Но: загрузка программ из этой библиотеки осуществляется "упрощенным" супреви-
зором ввода-вывода (он работает в условиях сбоев!); он не "ловит" данную
ошибку на диске, а просто загружает не ту программу, которую надо, а следу-
ющую за ней. Эта программа предназначена для совершенно иной ситуации - она
получает на вход некорректные данные и возникает ошибка типа деления на 0.
Супервизор ОС фиксирует ситуацию "программное прерывание в программе обра-
ботки машинных ошибок" и "принимает решение": аварийно завершить текущую
задачу. Текущая задача - КРОС (ака НASP) - достаточно "вылизан", и ситуация
"аварийное завершение" лежит вне его понимания - он перехватывает "сигнал"
об аварийном завершении и уходит в цикл под закрытой маской. Финиш.

Сильно ? :) А теперь мораль: просто_ предусматриваются _одиночные
сбои в системе. А вот ситуации одновременного возникновения двух независимых
сбоев предусмотреть невозможно ввиду астрономического числа вариантов. Также
невозможно предусмотреть влияние друг на друга аварийных подсистем разных
частей системы. И это относится к любой достаточно сложной системе, будь это
просто компьютер или электростанция. То-есть, с какого-то момента, поведение
системы становится в принципе не прогнозируемым. Можно говорить лишь о
вероятности того что ничего непредвиденного не произойдет, скажем 99%. А 1%
- воля божья :)))
--
Stanislav Latishko

@@ sl @ sl . spb . su ; 2:5030/949 @@
--- ifmail v.2.14

Valentin Davydov написал(а) к Stanislav Latishko в Jun 06 16:45:48 по местному времени:

From: Valentin Davydov <val@sqdp.trc-net.co.jp>

> From: Stanislav Latishko
> <Stanislav.Latishko@f949.n5030.z2.fidonet.org>
> Date: Thu, 01 Jun 2006 09:20:23 +0400
>
>VD> Критика тут тоже психологиеского характера. Программисты, нацеленные на
>VD> создание работающей системы, часто не знают, что делать в случае, когда
>VD> что-то не работает (exception handling на ихнем жаргоне). То есть даже
>VD> если принудительно заставить программиста проверять на нуль перед
>VD> делением, при попадании-таки нуля в знаменатель максимум, что сможет
>VD> сделать программист - вывести диагностическое сообщение и отправить
>VD> систему в перезагрузку. Что, собственно, и было продемонстрировано
>VD> в своё время Арианом-5.
>
> Ты несколько упрощаешь.
>
> Расскажу для начала маленькую байку из собственной жизни :) Байка
>не для этой эхи, но чертовски философски-поучительная :), а народ все-таки
>б-менее компьютерно-грамотный, поймет :) Итак, дано: лохматый год, ЕС ЭВМ.
>Машина наглухо виснет при неготовности АЦПУ. Раскручиваю причину и тихо
>офигеваю... Неготовность АЦПУ рассматривается ОС как ситуация "сбой обору-
>дования" и обрабатывается одной из программ обработки машинных ошибок,
>расположенной в специальной библиотеке. На диске, перед блоком, содержащим
>данную конкретную программу имеется ошибка вида "отсутствие адресного маркера".
>Но: загрузка программ из этой библиотеки осуществляется "упрощенным" супреви-
>зором ввода-вывода (он работает в условиях сбоев!); он не "ловит" данную
>ошибку на диске, а просто загружает не ту программу, которую надо, а следу-
>ющую за ней. Эта программа предназначена для совершенно иной ситуации - она
>получает на вход некорректные данные и возникает ошибка типа деления на 0.
>Супервизор ОС фиксирует ситуацию "программное прерывание в программе обра-
>ботки машинных ошибок" и "принимает решение": аварийно завершить текущую
>задачу. Текущая задача - КРОС (ака НASP) - достаточно "вылизан", и ситуация
>"аварийное завершение" лежит вне его понимания - он перехватывает "сигнал"
>об аварийном завершении и уходит в цикл под закрытой маской. Финиш.
>
> Сильно ? :)

Да нет, видна совершенно стандартная ошибка в двух разных модулях. Причём
ошибка ровно та же самая: при написании модуля программист благодушно
предполагал, что внешние, то есть из неподконтрольного программе источника,
данные сформатированы определённым образом, и не предусмотрел адэкватной
(или хотя бы документированной) реакции на случаи, когда это не так. Но ты
не переживай, эта ошибка и по сей день не потеряла своей актуальности, чему
ярким примером служат vulnerabilities, с завидной регулярностью находимые
в микрософтовских библиотеках обработки всякоразличной мультимедии, тягяемой
из интернета.

>А теперь мораль: просто_ предусматриваются _одиночные сбои в системе.

Нет, мораль другая: делать надо хорошо, а плохо оно само получится.
Ведь разработчики программ, имеющих дело с произвольными данными
(архиваторов, к примеру), не ленятся почему-то проверять корректность
входной информации, когда это важно (при распаковке архива).

>А вот ситуации одновременного возникновения двух независимых
>сбоев предусмотреть невозможно ввиду астрономического числа вариантов.

Да занефиг делать. На любом DVD этих двойных сбоев - уйма.

>Также
>невозможно предусмотреть влияние друг на друга аварийных подсистем разных
>частей системы.

Отсюда мораль: аварийные подсистемы должны работать автономно и не зависеть
от других систем.

>И это относится к любой достаточно сложной системе, будь это
>просто компьютер или электростанция.

Инфузория-туфелька устроена на порядки сложнее электростанции, тем не менее,
её поведение человечество научилось предсказывать с завидной точностью.

Вал. Дав.

--- ifmail v.2.15dev5.3

Andrey Platonov написал(а) к Stanislav Latishko в Jun 06 17:36:58 по местному времени:

From: "Andrey Platonov" <av_platon@interami.com>

Thu Jun 01 2006 09:31, Stanislav Latishko wrote to "Andrey Platonov":

AP>> Можно предусмотреть ТАКУЮ ситуацию на будущее. Но продвинутый раззява
AP>> создаст еще десяток подобных ситуаций. Будет бег по кругу, вырваться из
AP>> которого можно только нормальной организацией летной работы вообще и
AP>> повышением уровня подготовки экипажей в частности.
SL> Есть еще один аспект проблемы, о котором сторонники автоматизации
SL> всего совершенно не думают: чем выше надежность системы, чем реже она
SL> дает сбои, тем сильней "расслабляется" человек, тем ниже его готовность
SL> перехва- тить управление у свихнувшегося автомата. И когда случается
SL> очередная авария потому что человек просто не успел понять что автомат
SL> отказал, это повод
SL> опять говорить о том что человек ненадежен, что его надо вообще
SL> отстранить от управления. Процесс с положительной обратной связью.

Это ты не меня ли записал в сторонники автоматизации всего?

--- ifmail v.2.15dev5

Mikhail Akopov написал(а) к Stanislav Latishko в Jun 06 18:13:00 по местному времени:

From: Mikhail Akopov <bedal@mw.narzan.com>

Stanislav Latishko <Stanislav.Latishko@f949.n5030.z2.fidonet.org>
wrote:
> Есть еще один аспект проблемы, о котором сторонники автоматизации
>всего совершенно не думают: чем выше надежность системы, чем реже она дает
>сбои, тем сильней "расслабляется" человек, тем ниже его готовность перехва-
>тить управление у свихнувшегося автомата. И когда случается очередная авария
>потому что человек просто не успел понять что автомат отказал, это повод
>опять говорить о том что человек ненадежен, что его надо вообще отстранить
>от управления. Процесс с положительной обратной связью.
не хватает только логичного вывода: скрипач не нужен. Вообще.

Vale! - Михаил Акопов.
============================================================
Миша заставил читать, так надо читать... (Зевает и читает.)
/А.П.Чехов/

--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5.3

Mikhail Akopov написал(а) к Andrey Platonov в Jun 06 18:16:36 по местному времени:

From: Mikhail Akopov <bedal@mw.narzan.com>

"Andrey Platonov" <av_platon@interami.com> wrote:

>Thu Jun 01 2006 09:31, Stanislav Latishko wrote to "Andrey Platonov":
>
> SL> Есть еще один аспект проблемы, о котором сторонники автоматизации
> SL> всего совершенно не думают: чем выше надежность системы, чем реже она
...
>Это ты не меня ли записал в сторонники автоматизации всего?
тебя, тебя. Меня он ещё не засёк :)

Vale! - Михаил Акопов.
============================================================
Миша заставил читать, так надо читать... (Зевает и читает.)
/А.П.Чехов/

--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5.3

Cyrill Rozhin написал(а) к Sergey Chelyshev в May 06 21:24:24 по местному времени:

Попутного ветpа Sergey!
однажды (31.05.2006 8:30:36) Sergey Chelyshev написал(а) Cyrill Rozhin

CR>> Знаю, что пеpед 1991 г и pядом дpугих опеpаций, напpимеp в
CR>> Югославии, они сpочно снимали пpи помощи самолетов, обоpудованных
CR>> специальными РЛС с синтезиpованной апеpтуpой. Т.е. вывод - каpт всего
SC> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SC> Какое словосочетание кpасивое! Можете истолковать?
Апеpтуpа антенны синтезиpуется за счет обpаботки сигнала пpи
пеpемещении РЛС.


С уважением Киpилл,
С.-Пб.
--- FTNed 2001 Build 0063-RC10/Win2k

Vsevolod Koliubakin написал(а) к Mikhail Akopov в Jun 06 19:28:58 по местному времени:

From: "Vsevolod Koliubakin" <vkolyubakin@yandex.ru>

Thu Jun 01 2006 18:13, Mikhail Akopov wrote to Stanislav Latishko:
>> от управления. Процесс с положительной обратной связью.

MA> не хватает только логичного вывода: скрипач не нужен. Вообще.
Кстати, если мне память ни с кем не изменяет, буквально на днях самый
эхотажный фильм всех времён и народов :-) отметил два десятка.
Ку!!!

Всего наилучшего. Севыч.

--- ifmail v.2.15dev5

Sergey Broudkov написал(а) к Mikhail Akopov в Jun 06 21:17:22 по местному времени:

From: "Sergey Broudkov" <broudkov@pointltd.com>

Нello, Mikhail!
You wrote to Stanislav Latishko on Thu, 1 Jun 2006 14:13:00 +0000 (UTC):

>> Есть еще один аспект проблемы, о котором сторонники автоматизации
>> всего совершенно не думают: чем выше надежность системы, чем реже она
>> дает сбои, тем сильней "расслабляется" человек, тем ниже его готовность
>> перехва- тить управление у свихнувшегося автомата. И когда случается
>> очередная авария потому что человек просто не успел понять что автомат
>> отказал, это повод опять говорить о том что человек ненадежен, что его
>> надо вообще отстранить от управления. Процесс с положительной обратной
>> связью.
MA> не хватает только логичного вывода: скрипач не нужен. Вообще.

Другой не менее логичный вывод: автоматизация не нужна. Вообще. Ибо стоит
только нАчать, и поехало. Процесс с положительной обратной связью, как было
сказано. "Искореним автоматизацию на каждом рабочем месте!" Ну и
вейсманизм-морганизм заодно...

--
Regards,
Sergey Broudkov
sbpro@geocities.com
ICQ #4841919

--- ifmail v.2.15dev5.3