Здравствуйте, Erop, Вы писали:
G>>Мораль — клиент меняется, сервер — нет. И как тут быть с изменением структур ? E>А что, возможность засунуть в этот кубокилометр бетона, куда даже потелнетиться дают только по писменному разрешению президента, так вот, засунуть в это устройство произвольный код в любой момент времени с любого клиента -- это конечно не нарушение секьюрности...
Это все же гораздо безопаснее — так как деструктивный код там выполняться не может. А если что и сдохнет в процессе выполнения — то это будет прямое следование заповедям : "Let them crash !". Конечно, тут можно придумать нехорошие варианты : например, телеуправление — но как раз ТАКИЕ вещи лучше делать максимально жесткими. К счастью, периферийное телемеханическое железо имеет очень ограниченный ассортимент
E>Да вас, с такой архитектурой приговорят к пожизненному расстрелу через повешенье, однозначно!
А куда деваться ?
Собственно, пример был с бокситового рудника. многие тысячи точек сбора данных, сотни точек управления, в том числе много критических ( подьемники, воздухоподача, водооткачка )
Здравствуйте, gandalfgrey, Вы писали:
G>Собственно, пример был с бокситового рудника. многие тысячи точек сбора данных, сотни точек управления, в том числе много критических ( подьемники, воздухоподача, водооткачка )
Интересно, откуда в этом оборудовании может взяться неожиданный формат данных? Казалось бы, сериализуй всё в XML и не страдай гемором...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Интересно, откуда в этом оборудовании может взяться неожиданный формат данных? Казалось бы, сериализуй всё в XML и не страдай гемором...
Очень даже просто : добрые дядьки-КИПовцы проезжали мимо прибора, ну и решили сменить у него прошивку. Или на промежуточном сервере сбора данных потребовались вычисления, которые раньше никому нужны не были. Я уже приводил пример — считаются потери активной и реактивной мощности по фазам. Причем коэффициенты для разных фаз разные. Надо отослать туда уставки и получить обратно данные в новом формате.
Или вот вышла новая корпоративная инструкция, которая предписывает, ЧТО надо собирать для отчетности. В качестве абстрактного примера — собирать и отдавать произведение температуры прибора на частоту питающей сети с разбивкой по 15-сек интервалам на 5 минут до и после текущей точки времени.
ХМЛ — всего лишь средство представления данных, а ведь их надо еще как-то посчитать и интерпретировать
Здравствуйте, Erop, Вы писали:
G>>Собственно, пример был с бокситового рудника. многие тысячи точек сбора данных, сотни точек управления, в том числе много критических ( подьемники, воздухоподача, водооткачка )
E>Интересно, откуда в этом оборудовании может взяться неожиданный формат данных? Казалось бы, сериализуй всё в XML и не страдай гемором...
Да тут не в формате данных дело. А в том, чтобы на сервере можно было софт упдейтить когда разработчикам софта заблагорассудится. Вот, на космических зондах умудряются программы обновлять "на лету" (знаю про один случай, когда патчили Lisp-овую программу, и, кажется, на каком-то из марсианских зондах удаленно софт обновляли), поэтому людям хочется сделать это и на рудниках.
Все это выглядит попыткой найти техническое решение социальной проблемы. Если оборудование удалено и доступ к нему строго лимитирован, то у разработчиков возник соблазн: "а давайте сделаем так, чтобы нашу программу можно было патчить ни у кого не спрашивая и никому об этом не говоря". Мол, зачем разрешение на ssh-сессию испрашивать, если можно прямо в прикладном протоколе выслать новую функцию по управлению водооткачкой и не парится. Тем более, что если делать это тайком (от заказчика), то можно не проходить никаких новых приемо-сдаточных испытаний.
Имхо, вместо того, чтобы искать хитрые способы сериализации данных для статически-типизированных языков, гораздо лучше согласовать с заказчиком процедуры удаленного обновления ПО. Чтобы заказчик четко знал, что у него может происходить, а чего не может.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Имхо, вместо того, чтобы искать хитрые способы сериализации данных для статически-типизированных языков, гораздо лучше согласовать с заказчиком процедуры удаленного обновления ПО. Чтобы заказчик четко знал, что у него может происходить, а чего не может.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, eao197, Вы писали:
E>Да тут не в формате данных дело. А в том, чтобы на сервере можно было софт упдейтить когда разработчикам софта заблагорассудится. Вот, на космических зондах умудряются программы обновлять "на лету" (знаю про один случай, когда патчили Lisp-овую программу, и, кажется, на каком-то из марсианских зондах удаленно софт обновляли), поэтому людям хочется сделать это и на рудниках.
Не совсем так. Если бы дело было в одном только апдейте — то Ерланг, к примеру, предоставляет такую возможность прямо из коробки. Но все сложнее — производить горячую замену софта мало кто решится, и согласование разрешений на это — процесс не быстрый. И я их вполне могу понять : мало ли что там разработчики нацарапали, и дажн тесты не гарантируют 100 % надежности. Другое дело — когда уже работающий софт может адаптироваться ( в определенных пределах ) к изменившимся условиям и требованиям.
E>Все это выглядит попыткой найти техническое решение социальной проблемы. Если оборудование удалено и доступ к нему строго лимитирован, то у разработчиков возник соблазн: "а давайте сделаем так, чтобы нашу программу можно было патчить ни у кого не спрашивая и никому об этом не говоря". Мол, зачем разрешение на ssh-сессию испрашивать, если можно прямо в прикладном протоколе выслать новую функцию по управлению водооткачкой и не парится. Тем более, что если делать это тайком (от заказчика), то можно не проходить никаких новых приемо-сдаточных испытаний.
Надо заметить, что стандарты на телемеханические и телеметрические протоколы предусматривают передачу алгоритмов в качестве конфигурационных данных. Но доля истины в этом утверждении есть — конечно, тайком от заказчика делать этого никто не будет — просто ему самому спокойнее, когда бинарники работают те же самые, что и год назад.
E>Имхо, вместо того, чтобы искать хитрые способы сериализации данных для статически-типизированных языков, гораздо лучше согласовать с заказчиком процедуры удаленного обновления ПО. Чтобы заказчик четко знал, что у него может происходить, а чего не может.
Скажем так — потребности в этом возникают куда чаще возможностей.
А по поводу статически-типизированных языков — пока что обновляются форматы и алгоритмы для Ерланга и для навесных скриптов на Тикле. На С++ это уж слишком зловеще выглядит ( и не стоит выделки ).
Здравствуйте, gandalfgrey, Вы писали:
G>Не совсем так. Если бы дело было в одном только апдейте — то Ерланг, к примеру, предоставляет такую возможность прямо из коробки. Но все сложнее — производить горячую замену софта мало кто решится, и согласование разрешений на это — процесс не быстрый. И я их вполне могу понять : мало ли что там разработчики нацарапали, и дажн тесты не гарантируют 100 % надежности. Другое дело — когда уже работающий софт может адаптироваться ( в определенных пределах ) к изменившимся условиям и требованиям.
Смена формата представления данных в протоколе сложно назвать "определенными пределами".
G>А по поводу статически-типизированных языков — пока что обновляются форматы и алгоритмы для Ерланга и для навесных скриптов на Тикле. На С++ это уж слишком зловеще выглядит ( и не стоит выделки ).
Для C++ все уже давно придумали -- ssh. И для разработчиков спокойнее -- все их действия протоколируются и заказчик не сможет заявить, что вы обновили софт и у нас двигатель на насосе сгорел.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, gandalfgrey, Вы писали:
ГВ>>В каком-то смысле — всё вокруг одно и то же, и сегодня тот же день, что был вчера (c). Я имел в виду, что самоописание данных вполне можно заменить указанием номера версии, который сопоставляется всей группе описаний. В вычислительносм смысле такой подход может оказаться дешевле и проще, чем парсинг и анализ каждого пакета. G>Это дороже в организационном плане. Перепутать нумерацию версий — это просто праздник какой-то. Который случается намного чаще, чем нам хотелось бы.
Хотел спросить: "При чём тут организационная составляющая?", потом понял, что таки да — при чём.
ГВ>>Нет, разумеется. Версии протоколов придумывает человек. Человек же придумывает разные обновления для форматов и видов передаваемых данных. G>Опять-таки : а обновление протоколов будет происходить телепатически ? Ну нет у нас доступа к серверу ! Или же он крайне затруднен
Как я понимаю, ты про эту ситуацию:
[...] серверная часть :
— находится в 120 км от ближайшего диспетчерского пункта ( телнета там нет )
— доступ к серверу оформляется через 6 бумажек и месяц ожидания
— сервер просто замурован в будку с подогревом
— и апофеоз всего — никто просто не знает, где же он находится физически
Напоминаю — телнета НЕТ. ( по причинам безопасности в основном ). Или доступ через SSH открывают по официальному запросу
Мораль — клиент меняется, сервер — нет. И как тут быть с изменением структур ?
По уму тут надо менять процедуру открытия доступа через SSH. А то у вас интересно получается — физически к серверу доступа нет, а в "электронном" смысле не то что доступ есть, а просто автострада. Скорее всего, кто-то попросту закрыл глаза на какие-то пункты инструкций, использовав, например, то, что там ничего не говорилось о возможностях Erlang. А так и инструкции "соблюдены", и софт обновляется. Если бы сервер на самом деле хотели защитить, то вам не позволили бы оставлять такие "закладки" в протоколе. Ага, это чаще всего называется именно так — закладка для неконтролируемого обновления. Если ты хотел узнать про апофеоз, то вот это он и есть на самом деле.
ГВ>>Приёмник ничего и никогда не сможет решить, если методы "решения" ему не предписаны заранее. А если такие методы предписаны — решение переходит в тривиальную фазу. Хоть с подгрузкой программ, хоть с подгрузкой распознавателей, хоть с описанием данных. Понимаешь, о чём я? То есть снова возвращаемся к тому, что первоначально приёмник и передатчик должны располагать некоторым "описанием" передаваемых данных и способа их обработки. G>Или же описанием того, как и где применять НОВЫЕ способы обработки.
Что есть частный случай известного обоим сторонам описания передаваемых данных.
ГВ>>Безусловно. Вопрос в цене этой самой гибкости. Нет, я не спорю, в предельном случае может оказаться правильным вообще подгружать нужную программу по любому чиху. Но так можно дообобщаться до многого. G>Что поделать ! Такова селява. Хотя, конечно, нужет какой-то баланс между крайней гибкостью и полной окостенелостью обработки пакетов.
Да нет. Селява здесь в требованиях нормативных документов и технических нюансах систем программирования.
ГВ>>Хех. Новые данные требуют новых программ для их обработки, не правда ли? G>Если бы так ! Народ жаждет, чтобы один и тот же софт делал ВСЕ. А так как оный народ платит денюжку, то...
Ну опять ты за своё. Народ на самом деле жаждет на ёлку влезть... То есть он жаждет, чтобы формальные требования к процедурам соблюдались, но в то же время ПО обновлялось без особых заморочек. Менять процедуры хлопотно и лишняя ответственность, проходить их каждый раз, считай — прибить дело на корню, посему попросту обойти их — гораздо проще. Пусть даже для этого придётся назвать динамически обновляемое ПО "одной и той же версией", что может быть корректным по каким-то формальным признакам.
Таким образом, народ жаждет, чтобы можно было назвать ПО "одним и тем же", даже если оно сто раз переобновлено. И народ, само собой, нашёл такой способ: "новым" ПО дозволяется называть после прохождения формальной процедуры приёмки, а до того — это "неизменное ПО" с "обновляемыми сценариями", или как-то так. Вполне вероятно, что термин "обновляемый" вообще не фигурирует в документации.
Короче говоря, теперь начинается сага о терминах и их трактовках в разных контекстах, только и всего. А ты пытаешься на этом основании чуть ли не фундаментальные законы информационных технологий сотрясти.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandalfgrey, Вы писали:
E>>Да тут не в формате данных дело. А в том, чтобы на сервере можно было софт упдейтить когда разработчикам софта заблагорассудится. Вот, на космических зондах умудряются программы обновлять "на лету" (знаю про один случай, когда патчили Lisp-овую программу, и, кажется, на каком-то из марсианских зондах удаленно софт обновляли), поэтому людям хочется сделать это и на рудниках. G>Не совсем так. Если бы дело было в одном только апдейте — то Ерланг, к примеру, предоставляет такую возможность прямо из коробки. Но все сложнее — производить горячую замену софта мало кто решится, и согласование разрешений на это — процесс не быстрый. И я их вполне могу понять : мало ли что там разработчики нацарапали, и дажн тесты не гарантируют 100 % надежности. Другое дело — когда уже работающий софт может адаптироваться ( в определенных пределах ) к изменившимся условиям и требованиям.
Вот-вот. Ключевое слово — процедура обновления. Сопряжённые термины: ответственность, делегирование, полномочия, допуск.
E>>Все это выглядит попыткой найти техническое решение социальной проблемы. [...] G>Надо заметить, что стандарты на телемеханические и телеметрические протоколы предусматривают передачу алгоритмов в качестве конфигурационных данных. Но доля истины в этом утверждении есть — конечно, тайком от заказчика делать этого никто не будет — просто ему самому спокойнее, когда бинарники работают те же самые, что и год назад.
Да, да, да. Ему самому спокойнее, даже если эти бинарники уже отодвинуты в дальний угол.
E>>Имхо, вместо того, чтобы искать хитрые способы сериализации данных для статически-типизированных языков, гораздо лучше согласовать с заказчиком процедуры удаленного обновления ПО. Чтобы заказчик четко знал, что у него может происходить, а чего не может. G>Скажем так — потребности в этом возникают куда чаще возможностей.
G>А по поводу статически-типизированных языков — пока что обновляются форматы и алгоритмы для Ерланга и для навесных скриптов на Тикле. На С++ это уж слишком зловеще выглядит ( и не стоит выделки ).
Зловеще выглядит "подгрузка исполняемого кода". А интерпертируемые скрипты — не страшно. Они ж интерпретируемые — чего их бояться-то?!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandalfgrey, Вы писали:
E>>Интересно, откуда в этом оборудовании может взяться неожиданный формат данных? Казалось бы, сериализуй всё в XML и не страдай гемором... G>Очень даже просто : добрые дядьки-КИПовцы проезжали мимо прибора, ну и решили сменить у него прошивку.
Оригиналы они, эти дядьки-КИПовцы. То есть они могут привести устройство в нерабочее состояние, так, что ли?
G>Или на промежуточном сервере сбора данных потребовались вычисления, которые раньше никому нужны не были. Я уже приводил пример — считаются потери активной и реактивной мощности по фазам. Причем коэффициенты для разных фаз разные. Надо отослать туда уставки и получить обратно данные в новом формате.
Ну и что? Ничего же из ниоткуда не берётся, так или иначе — сначала устаканивается сам формат данных, а прежде оного устканства появляется требование.
G>Или вот вышла новая корпоративная инструкция, которая предписывает, ЧТО надо собирать для отчетности. В качестве абстрактного примера — собирать и отдавать произведение температуры прибора на частоту питающей сети с разбивкой по 15-сек интервалам на 5 минут до и после текущей точки времени.
И что? Если приборы могут передавать эти данные — мы их собираем. Если не могут — обновляем прошивку с помощью КИПовцев. В любом случае про ожидаемое изменение форматов и набора данных известно заранее — у нас же есть корпоративная инструкция, предписывающая "научить" устройства таким фортелям.
G>ХМЛ — всего лишь средство представления данных, а ведь их надо еще как-то посчитать и интерпретировать
О том и диспут.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandalfgrey, Вы писали:
G>>>Мораль — клиент меняется, сервер — нет. И как тут быть с изменением структур ? E>>А что, возможность засунуть в этот кубокилометр бетона, куда даже потелнетиться дают только по писменному разрешению президента, так вот, засунуть в это устройство произвольный код в любой момент времени с любого клиента -- это конечно не нарушение секьюрности... G>Это все же гораздо безопаснее — так как деструктивный код там выполняться не может.
Деструктивный — это вовсе не тот, который приводит к core dump. Вернее — не только он. Например, деструктивный код может фальсифицировать данные о температуре прибора, из-за чего этот прибор будет неправильно охлаждаться. Из прибора пойдёт дым, или он покроется инеем, или выдаст кривую команду на управляющие системы. Но при этом всё пройдёт тихо и гладко с точки зрения ОС — даже мусоросборщик отработает. Так что core dump — это так, страшилка для кулхацкеров.
Так вот, то, что вам дают возможность апдейтить код, как вам вздумается (сиречь — по упрощённой процедуре) — это означает, что ответственные лица в организации-заказчике снимают (частично) с себя ответственность за подобные последствия. А фигли? Ничего деструктивного не выполняется — это программисты во всём виноваты. И вместо того, чтобы развивать содержательную часть приёмо-сдаточных испытаний — переваливают ответственность за последствия полностью на вас.
G>А если что и сдохнет в процессе выполнения — то это будет прямое следование заповедям : "Let them crash !". Конечно, тут можно придумать нехорошие варианты : например, телеуправление — но как раз ТАКИЕ вещи лучше делать максимально жесткими. К счастью, периферийное телемеханическое железо имеет очень ограниченный ассортимент
Оригинальненько так: Let them crash, особенно в контексте того, о чём ты написал ниже.
E>>Да вас, с такой архитектурой приговорят к пожизненному расстрелу через повешенье, однозначно! G>А куда деваться ?
Работать надо, как это ни удивительно. А не надеяться на IT-шное словоблудство.
G>Собственно, пример был с бокситового рудника. многие тысячи точек сбора данных, сотни точек управления, в том числе много критических ( подьемники, воздухоподача, водооткачка )
Для деструктивного кода поле широчайшее, к сожалению. Шире просто представить невозможно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Erop, Вы писали:
E>Да вас, с такой архитектурой [...]
Вот вам и способ "выстрелить самому себе в ногу" на Эрланге, Лиспе и куче других языков. С++ в сравнении с ними — дитё розовощёкое.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>А фигли? Ничего деструктивного не выполняется — это программисты во всём виноваты.
И самое главное — документы-то все в порядке. И никаких формальных нарушений — все ответственные лица ответственно выполнили свою ответственную работу с документами приёмо-сдаточных испытаний.
G>>К счастью, периферийное телемеханическое железо имеет очень ограниченный ассортимент
Если я тебя правильно понял, то это многое объясняет. Например, вам может быть позволено играться, потому что сама аппаратура обладает необходимой надёжностью по параметрам управления, а способы наблюдения (сиречь — форматирование и преобразование данных наблюдений) уже не так критичны, это всего лишь плюс-минус удобство. Правду сказать, в это мне верится гораздо больше, чем в паталогический идиотизм управленцев.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandalfgrey, Вы писали:
G>Надо заметить, что стандарты на телемеханические и телеметрические протоколы предусматривают передачу алгоритмов в качестве конфигурационных данных. Но доля истины в этом утверждении есть — конечно, тайком от заказчика делать этого никто не будет — просто ему самому спокойнее, когда бинарники работают те же самые, что и год назад.
Вот природу этого спокойствия хотелось бы понять поточнее.
На мой взгляд, вменяемому клиенту более-менее всё равно, какой из компонентов системы уязвим. Вон, у сендмейла бинарники всегда "те же самые", зато конфиг надо беречь как зеницу ока.
Если имеется в виду то, что сервер типа не изменился; стоит начать посылать на него пакеты в старом формате — и всё починится, то я не понимаю в чем принципиальная разница с удаленной перепрошивкой. Потому что с ней "стоит перепрошить на сентябрьскую версию из SVN — и всё починится".
Зато есть некоторые опасения. Грубо говоря, смена "жесткого" протокола и связанная с ней перепрошивка — операция редкая и привилегированная. Все они лежат в логе; всегда точно известно, кто когда что и на что менял. В случае per-message изменения кода, для анализа катастрофы нужен полный лог всех сообщений.
Типа вот сорвало у нас предохранительный клапан; почему — оказывается один из пакетов в экспериментальных целях передал некий коэффициент в виде byte, а не int; после десериализации это привело к целому переполнению при умножении, и на управляемое устройство пошёл не тот сигнал.
Как ты будешь отлавливать такие ситуации? Вроде смотрим — всё нормально; в системе — ни следа от вредоносного кода; откуда взялся запредельный параметр — невозможно понять.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>По уму тут надо менять процедуру открытия доступа через SSH. А то у вас интересно получается — физически к серверу доступа нет, а в "электронном" смысле не то что доступ есть, а просто автострада. Скорее всего, кто-то попросту закрыл глаза на какие-то пункты инструкций, использовав, например, то, что там ничего не говорилось о возможностях Erlang. А так и инструкции "соблюдены", и софт обновляется. Если бы сервер на самом деле хотели защитить, то вам не позволили бы оставлять такие "закладки" в протоколе. Ага, это чаще всего называется именно так — закладка для неконтролируемого обновления. Если ты хотел узнать про апофеоз, то вот это он и есть на самом деле.
Тут есть еще одно "НО" — а именно, рестарт системы при замене софта цивильным способом занимает много времени. Горячее обновление кода не спасает ситуацию, поскольку присутствуют и модули на Ерланге, и на С++, и на Тикле. Причем конфигурация многосерверная, что еще более замедляет подьем системы. Модуль-концентратор на С++ написан 7 лет назад, и при достаточно больших базах может стартовать несколько часов. Все это время система частично функциональна.
ГВ>Что есть частный случай известного обоим сторонам описания передаваемых данных.
Ну разумеется, в любом случае мы исходим из наших знаний о железе и процессе работы с ним. Так что можно назвать это знание ПРЕДОПРЕДЕЛЕННЫМ
ГВ>Да нет. Селява здесь в требованиях нормативных документов и технических нюансах систем программирования.
А это гораздо хуже...
ГВ>Ну опять ты за своё. Народ на самом деле жаждет на ёлку влезть... То есть он жаждет, чтобы формальные требования к процедурам соблюдались, но в то же время ПО обновлялось без особых заморочек. Менять процедуры хлопотно и лишняя ответственность, проходить их каждый раз, считай — прибить дело на корню, посему попросту обойти их — гораздо проще. Пусть даже для этого придётся назвать динамически обновляемое ПО "одной и той же версией", что может быть корректным по каким-то формальным признакам.
Вот она, сермяжно-посконная правда ! Все так и есть
ГВ>Таким образом, народ жаждет, чтобы можно было назвать ПО "одним и тем же", даже если оно сто раз переобновлено. И народ, само собой, нашёл такой способ: "новым" ПО дозволяется называть после прохождения формальной процедуры приёмки, а до того — это "неизменное ПО" с "обновляемыми сценариями", или как-то так. Вполне вероятно, что термин "обновляемый" вообще не фигурирует в документации.
А вот уже уже утрирование
ГВ>Короче говоря, теперь начинается сага о терминах и их трактовках в разных контекстах, только и всего. А ты пытаешься на этом основании чуть ли не фундаментальные законы информационных технологий сотрясти.
Не, даже не помышлял такого ! И чего, собственно, революционного в передаче алгоритмов по проводам ? В любом случае, расчетные скрипты являются частью файла конфигурации. А подмена конфигурации ДОЛЖНА осуществляться без полного перезапуска системы
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Вот-вот. Ключевое слово — процедура обновления. Сопряжённые термины: ответственность, делегирование, полномочия, допуск.
Не пробовали сказать такие слова какому-либо мелкому/среднему боссу в большой корпорации ? Кивать с умным видом они, конечно, будут — но это и все !
ГВ>Да, да, да. Ему самому спокойнее, даже если эти бинарники уже отодвинуты в дальний угол.
Ежели говорить формально — то бинарники те же, что и были.
ГВ>Зловеще выглядит "подгрузка исполняемого кода". А интерпертируемые скрипты — не страшно. Они ж интерпретируемые — чего их бояться-то?!
Скрипты проще ограничить в возможностях.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Оригиналы они, эти дядьки-КИПовцы. То есть они могут привести устройство в нерабочее состояние, так, что ли?
Запросто ! И не раз такое делали. Вот пример : есть такой агрегат, аппаратный концентратор УСПД. Работает крайне криво, но изготовители как бы работают над этим. Присылают новые прошивки и т.д. Но ! Эти прошивки работают корректно только на определенных модификациях агрегата. Определить это можно только разглядывая печатную плату.
ГВ>Ну и что? Ничего же из ниоткуда не берётся, так или иначе — сначала устаканивается сам формат данных, а прежде оного устканства появляется требование.
Господя ! Если б это было так ! Сначала требование, причем из разряда "вынь да положь"
ГВ>И что? Если приборы могут передавать эти данные — мы их собираем. Если не могут — обновляем прошивку с помощью КИПовцев. В любом случае про ожидаемое изменение форматов и набора данных известно заранее — у нас же есть корпоративная инструкция, предписывающая "научить" устройства таким фортелям.
В большинстве случаев — значительную часть данных высчитывает микросервер, на котором висит этот прибор.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Деструктивный — это вовсе не тот, который приводит к core dump. Вернее — не только он. Например, деструктивный код может фальсифицировать данные о температуре прибора, из-за чего этот прибор будет неправильно охлаждаться. Из прибора пойдёт дым, или он покроется инеем, или выдаст кривую команду на управляющие системы. Но при этом всё пройдёт тихо и гладко с точки зрения ОС — даже мусоросборщик отработает. Так что core dump — это так, страшилка для кулхацкеров.
Согласен.
ГВ>Так вот, то, что вам дают возможность апдейтить код, как вам вздумается (сиречь — по упрощённой процедуре) — это означает, что ответственные лица в организации-заказчике снимают (частично) с себя ответственность за подобные последствия. А фигли? Ничего деструктивного не выполняется — это программисты во всём виноваты. И вместо того, чтобы развивать содержательную часть приёмо-сдаточных испытаний — переваливают ответственность за последствия полностью на вас.
Неа — ответственность лежит всегда и только на диспетчерах. Только человек может оценить ситуацию и принять решение. Например, расходомер стока воды показывает, что поток резко убыл. А потребляемая мощность автономного насоса каскадом ниже увеличилась. И что делать, эвакуировать людей с горизонта или поставить расходомер в план ремонта ?
ГВ>Оригинальненько так: Let them crash, особенно в контексте того, о чём ты написал ниже.
Это имеет значение "пусть лучше оно сдохнет, чем неправильно отработает"
ГВ>Работать надо, как это ни удивительно. А не надеяться на IT-шное словоблудство.
Именно, что работать. А не заниматься беспрестанными приемо-сдачами. Словоблудство никому не нужно. А нужна людям работа оборудования, непрерывная, без остановок на наладку / конфигурирование.
ГВ>Для деструктивного кода поле широчайшее, к сожалению. Шире просто представить невозможно.
Это должен быть ПРЕДНАМЕРЕННО вредоносный код
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Вот вам и способ "выстрелить самому себе в ногу" на Эрланге, Лиспе и куче других языков. С++ в сравнении с ними — дитё розовощёкое.
Жизнь показывает иное — ежели падения или отказы ( по причине некорректности кода / входных данных / чего-то еще ) модулей на С++ случаются регулярно, то Ерланговские минисервера работают. Они просто работают. Годами.
Статистика на этот счет у меня богатая, так что переубедить меня будет сложно.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>И самое главное — документы-то все в порядке. И никаких формальных нарушений — все ответственные лица ответственно выполнили свою ответственную работу с документами приёмо-сдаточных испытаний.
Доля истины в этом есть, но только доля. Бумага и вправду прикрывает задницу, но это непрочный щит. И в случае затопления горизонта иметь будут всех, мало обращая внимания на бумажки. Потому как — денежные потери это удар по карману владельцев и топов
ГВ>Если я тебя правильно понял, то это многое объясняет. Например, вам может быть позволено играться, потому что сама аппаратура обладает необходимой надёжностью по параметрам управления, а способы наблюдения (сиречь — форматирование и преобразование данных наблюдений) уже не так критичны, это всего лишь плюс-минус удобство. Правду сказать, в это мне верится гораздо больше, чем в паталогический идиотизм управленцев.
Интересно, а как это предполагается принимать решение о включении / выключении чего-либо без данных о состоянии зависимых цепочек ?
И выражение "патологический идиотизм" некорректно. Это обычный корпоративный бюрократизм. Не без тупости, конечно...