Re[17]: Нужны примеры...
От: gandalfgrey  
Дата: 27.11.08 10:52
Оценка:
Здравствуйте, Erop, Вы писали:

G>>Мораль — клиент меняется, сервер — нет. И как тут быть с изменением структур ?

E>А что, возможность засунуть в этот кубокилометр бетона, куда даже потелнетиться дают только по писменному разрешению президента, так вот, засунуть в это устройство произвольный код в любой момент времени с любого клиента -- это конечно не нарушение секьюрности...
Это все же гораздо безопаснее — так как деструктивный код там выполняться не может. А если что и сдохнет в процессе выполнения — то это будет прямое следование заповедям : "Let them crash !". Конечно, тут можно придумать нехорошие варианты : например, телеуправление — но как раз ТАКИЕ вещи лучше делать максимально жесткими. К счастью, периферийное телемеханическое железо имеет очень ограниченный ассортимент

E>Да вас, с такой архитектурой приговорят к пожизненному расстрелу через повешенье, однозначно!

А куда деваться ?
Собственно, пример был с бокситового рудника. многие тысячи точек сбора данных, сотни точек управления, в том числе много критических ( подьемники, воздухоподача, водооткачка )
Re[18]: Нужны примеры...
От: Erop Россия  
Дата: 27.11.08 12:07
Оценка: +1
Здравствуйте, gandalfgrey, Вы писали:

G>Собственно, пример был с бокситового рудника. многие тысячи точек сбора данных, сотни точек управления, в том числе много критических ( подьемники, воздухоподача, водооткачка )


Интересно, откуда в этом оборудовании может взяться неожиданный формат данных? Казалось бы, сериализуй всё в XML и не страдай гемором...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[19]: Нужны примеры...
От: gandalfgrey  
Дата: 27.11.08 12:33
Оценка:
Здравствуйте, Erop, Вы писали:

E>Интересно, откуда в этом оборудовании может взяться неожиданный формат данных? Казалось бы, сериализуй всё в XML и не страдай гемором...

Очень даже просто : добрые дядьки-КИПовцы проезжали мимо прибора, ну и решили сменить у него прошивку. Или на промежуточном сервере сбора данных потребовались вычисления, которые раньше никому нужны не были. Я уже приводил пример — считаются потери активной и реактивной мощности по фазам. Причем коэффициенты для разных фаз разные. Надо отослать туда уставки и получить обратно данные в новом формате.
Или вот вышла новая корпоративная инструкция, которая предписывает, ЧТО надо собирать для отчетности. В качестве абстрактного примера — собирать и отдавать произведение температуры прибора на частоту питающей сети с разбивкой по 15-сек интервалам на 5 минут до и после текущей точки времени.
ХМЛ — всего лишь средство представления данных, а ведь их надо еще как-то посчитать и интерпретировать
Re[19]: Нужны примеры...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.11.08 12:38
Оценка: +3
Здравствуйте, Erop, Вы писали:

G>>Собственно, пример был с бокситового рудника. многие тысячи точек сбора данных, сотни точек управления, в том числе много критических ( подьемники, воздухоподача, водооткачка )


E>Интересно, откуда в этом оборудовании может взяться неожиданный формат данных? Казалось бы, сериализуй всё в XML и не страдай гемором...


Да тут не в формате данных дело. А в том, чтобы на сервере можно было софт упдейтить когда разработчикам софта заблагорассудится. Вот, на космических зондах умудряются программы обновлять "на лету" (знаю про один случай, когда патчили Lisp-овую программу, и, кажется, на каком-то из марсианских зондах удаленно софт обновляли), поэтому людям хочется сделать это и на рудниках.

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

Имхо, вместо того, чтобы искать хитрые способы сериализации данных для статически-типизированных языков, гораздо лучше согласовать с заказчиком процедуры удаленного обновления ПО. Чтобы заказчик четко знал, что у него может происходить, а чего не может.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: Нужны примеры...
От: Erop Россия  
Дата: 27.11.08 12:58
Оценка:
Здравствуйте, eao197, Вы писали:

E>Имхо, вместо того, чтобы искать хитрые способы сериализации данных для статически-типизированных языков, гораздо лучше согласовать с заказчиком процедуры удаленного обновления ПО. Чтобы заказчик четко знал, что у него может происходить, а чего не может.


+1
Мне тоже так кажется
Автор: Erop
Дата: 27.11.08
...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[20]: Нужны примеры...
От: gandalfgrey  
Дата: 27.11.08 13:04
Оценка: 1 (1)
Здравствуйте, eao197, Вы писали:

E>Да тут не в формате данных дело. А в том, чтобы на сервере можно было софт упдейтить когда разработчикам софта заблагорассудится. Вот, на космических зондах умудряются программы обновлять "на лету" (знаю про один случай, когда патчили Lisp-овую программу, и, кажется, на каком-то из марсианских зондах удаленно софт обновляли), поэтому людям хочется сделать это и на рудниках.

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

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

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

E>Имхо, вместо того, чтобы искать хитрые способы сериализации данных для статически-типизированных языков, гораздо лучше согласовать с заказчиком процедуры удаленного обновления ПО. Чтобы заказчик четко знал, что у него может происходить, а чего не может.

Скажем так — потребности в этом возникают куда чаще возможностей.
А по поводу статически-типизированных языков — пока что обновляются форматы и алгоритмы для Ерланга и для навесных скриптов на Тикле. На С++ это уж слишком зловеще выглядит ( и не стоит выделки ).
Re[21]: Нужны примеры...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.11.08 13:11
Оценка: +3
Здравствуйте, gandalfgrey, Вы писали:

G>Не совсем так. Если бы дело было в одном только апдейте — то Ерланг, к примеру, предоставляет такую возможность прямо из коробки. Но все сложнее — производить горячую замену софта мало кто решится, и согласование разрешений на это — процесс не быстрый. И я их вполне могу понять : мало ли что там разработчики нацарапали, и дажн тесты не гарантируют 100 % надежности. Другое дело — когда уже работающий софт может адаптироваться ( в определенных пределах ) к изменившимся условиям и требованиям.


Смена формата представления данных в протоколе сложно назвать "определенными пределами".

G>А по поводу статически-типизированных языков — пока что обновляются форматы и алгоритмы для Ерланга и для навесных скриптов на Тикле. На С++ это уж слишком зловеще выглядит ( и не стоит выделки ).


Для C++ все уже давно придумали -- ssh. И для разработчиков спокойнее -- все их действия протоколируются и заказчик не сможет заявить, что вы обновили софт и у нас двигатель на насосе сгорел.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: Сериализация и языки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.11.08 17:22
Оценка: +2
Здравствуйте, gandalfgrey, Вы писали:

ГВ>>В каком-то смысле — всё вокруг одно и то же, и сегодня тот же день, что был вчера (c). Я имел в виду, что самоописание данных вполне можно заменить указанием номера версии, который сопоставляется всей группе описаний. В вычислительносм смысле такой подход может оказаться дешевле и проще, чем парсинг и анализ каждого пакета.

G>Это дороже в организационном плане. Перепутать нумерацию версий — это просто праздник какой-то. Который случается намного чаще, чем нам хотелось бы.

Хотел спросить: "При чём тут организационная составляющая?", потом понял, что таки да — при чём.

ГВ>>Нет, разумеется. Версии протоколов придумывает человек. Человек же придумывает разные обновления для форматов и видов передаваемых данных.

G>Опять-таки : а обновление протоколов будет происходить телепатически ? Ну нет у нас доступа к серверу ! Или же он крайне затруднен

Как я понимаю, ты про эту ситуацию:

[...] серверная часть :
— находится в 120 км от ближайшего диспетчерского пункта ( телнета там нет )
— доступ к серверу оформляется через 6 бумажек и месяц ожидания
— сервер просто замурован в будку с подогревом
— и апофеоз всего — никто просто не знает, где же он находится физически
Напоминаю — телнета НЕТ. ( по причинам безопасности в основном ). Или доступ через SSH открывают по официальному запросу
Мораль — клиент меняется, сервер — нет. И как тут быть с изменением структур ?


По уму тут надо менять процедуру открытия доступа через SSH. А то у вас интересно получается — физически к серверу доступа нет, а в "электронном" смысле не то что доступ есть, а просто автострада. Скорее всего, кто-то попросту закрыл глаза на какие-то пункты инструкций, использовав, например, то, что там ничего не говорилось о возможностях Erlang. А так и инструкции "соблюдены", и софт обновляется. Если бы сервер на самом деле хотели защитить, то вам не позволили бы оставлять такие "закладки" в протоколе. Ага, это чаще всего называется именно так — закладка для неконтролируемого обновления. Если ты хотел узнать про апофеоз, то вот это он и есть на самом деле.

ГВ>>Приёмник ничего и никогда не сможет решить, если методы "решения" ему не предписаны заранее. А если такие методы предписаны — решение переходит в тривиальную фазу. Хоть с подгрузкой программ, хоть с подгрузкой распознавателей, хоть с описанием данных. Понимаешь, о чём я? То есть снова возвращаемся к тому, что первоначально приёмник и передатчик должны располагать некоторым "описанием" передаваемых данных и способа их обработки.

G>Или же описанием того, как и где применять НОВЫЕ способы обработки.

Что есть частный случай известного обоим сторонам описания передаваемых данных.

ГВ>>Безусловно. Вопрос в цене этой самой гибкости. Нет, я не спорю, в предельном случае может оказаться правильным вообще подгружать нужную программу по любому чиху. Но так можно дообобщаться до многого.

G>Что поделать ! Такова селява. Хотя, конечно, нужет какой-то баланс между крайней гибкостью и полной окостенелостью обработки пакетов.

Да нет. Селява здесь в требованиях нормативных документов и технических нюансах систем программирования.

ГВ>>Хех. Новые данные требуют новых программ для их обработки, не правда ли?

G>Если бы так ! Народ жаждет, чтобы один и тот же софт делал ВСЕ. А так как оный народ платит денюжку, то...

Ну опять ты за своё. Народ на самом деле жаждет на ёлку влезть... То есть он жаждет, чтобы формальные требования к процедурам соблюдались, но в то же время ПО обновлялось без особых заморочек. Менять процедуры хлопотно и лишняя ответственность, проходить их каждый раз, считай — прибить дело на корню, посему попросту обойти их — гораздо проще. Пусть даже для этого придётся назвать динамически обновляемое ПО "одной и той же версией", что может быть корректным по каким-то формальным признакам.

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

Короче говоря, теперь начинается сага о терминах и их трактовках в разных контекстах, только и всего. А ты пытаешься на этом основании чуть ли не фундаментальные законы информационных технологий сотрясти.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[21]: Нужны примеры...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.11.08 17:44
Оценка: +2
Здравствуйте, gandalfgrey, Вы писали:

E>>Да тут не в формате данных дело. А в том, чтобы на сервере можно было софт упдейтить когда разработчикам софта заблагорассудится. Вот, на космических зондах умудряются программы обновлять "на лету" (знаю про один случай, когда патчили Lisp-овую программу, и, кажется, на каком-то из марсианских зондах удаленно софт обновляли), поэтому людям хочется сделать это и на рудниках.

G>Не совсем так. Если бы дело было в одном только апдейте — то Ерланг, к примеру, предоставляет такую возможность прямо из коробки. Но все сложнее — производить горячую замену софта мало кто решится, и согласование разрешений на это — процесс не быстрый. И я их вполне могу понять : мало ли что там разработчики нацарапали, и дажн тесты не гарантируют 100 % надежности. Другое дело — когда уже работающий софт может адаптироваться ( в определенных пределах ) к изменившимся условиям и требованиям.

Вот-вот. Ключевое слово — процедура обновления. Сопряжённые термины: ответственность, делегирование, полномочия, допуск.

E>>Все это выглядит попыткой найти техническое решение социальной проблемы. [...]

G>Надо заметить, что стандарты на телемеханические и телеметрические протоколы предусматривают передачу алгоритмов в качестве конфигурационных данных. Но доля истины в этом утверждении есть — конечно, тайком от заказчика делать этого никто не будет — просто ему самому спокойнее, когда бинарники работают те же самые, что и год назад.

Да, да, да. Ему самому спокойнее, даже если эти бинарники уже отодвинуты в дальний угол.

E>>Имхо, вместо того, чтобы искать хитрые способы сериализации данных для статически-типизированных языков, гораздо лучше согласовать с заказчиком процедуры удаленного обновления ПО. Чтобы заказчик четко знал, что у него может происходить, а чего не может.

G>Скажем так — потребности в этом возникают куда чаще возможностей.



G>А по поводу статически-типизированных языков — пока что обновляются форматы и алгоритмы для Ерланга и для навесных скриптов на Тикле. На С++ это уж слишком зловеще выглядит ( и не стоит выделки ).


Зловеще выглядит "подгрузка исполняемого кода". А интерпертируемые скрипты — не страшно. Они ж интерпретируемые — чего их бояться-то?!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: Нужны примеры...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.11.08 18:31
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

E>>Интересно, откуда в этом оборудовании может взяться неожиданный формат данных? Казалось бы, сериализуй всё в XML и не страдай гемором...

G>Очень даже просто : добрые дядьки-КИПовцы проезжали мимо прибора, ну и решили сменить у него прошивку.

Оригиналы они, эти дядьки-КИПовцы. То есть они могут привести устройство в нерабочее состояние, так, что ли?

G>Или на промежуточном сервере сбора данных потребовались вычисления, которые раньше никому нужны не были. Я уже приводил пример — считаются потери активной и реактивной мощности по фазам. Причем коэффициенты для разных фаз разные. Надо отослать туда уставки и получить обратно данные в новом формате.


Ну и что? Ничего же из ниоткуда не берётся, так или иначе — сначала устаканивается сам формат данных, а прежде оного устканства появляется требование.

G>Или вот вышла новая корпоративная инструкция, которая предписывает, ЧТО надо собирать для отчетности. В качестве абстрактного примера — собирать и отдавать произведение температуры прибора на частоту питающей сети с разбивкой по 15-сек интервалам на 5 минут до и после текущей точки времени.


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

G>ХМЛ — всего лишь средство представления данных, а ведь их надо еще как-то посчитать и интерпретировать


О том и диспут.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[18]: Нужны примеры...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.11.08 18:52
Оценка: +3
Здравствуйте, gandalfgrey, Вы писали:

G>>>Мораль — клиент меняется, сервер — нет. И как тут быть с изменением структур ?

E>>А что, возможность засунуть в этот кубокилометр бетона, куда даже потелнетиться дают только по писменному разрешению президента, так вот, засунуть в это устройство произвольный код в любой момент времени с любого клиента -- это конечно не нарушение секьюрности...
G>Это все же гораздо безопаснее — так как деструктивный код там выполняться не может.

Деструктивный — это вовсе не тот, который приводит к core dump. Вернее — не только он. Например, деструктивный код может фальсифицировать данные о температуре прибора, из-за чего этот прибор будет неправильно охлаждаться. Из прибора пойдёт дым, или он покроется инеем, или выдаст кривую команду на управляющие системы. Но при этом всё пройдёт тихо и гладко с точки зрения ОС — даже мусоросборщик отработает. Так что core dump — это так, страшилка для кулхацкеров.

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

G>А если что и сдохнет в процессе выполнения — то это будет прямое следование заповедям : "Let them crash !". Конечно, тут можно придумать нехорошие варианты : например, телеуправление — но как раз ТАКИЕ вещи лучше делать максимально жесткими. К счастью, периферийное телемеханическое железо имеет очень ограниченный ассортимент


Оригинальненько так: Let them crash, особенно в контексте того, о чём ты написал ниже.

E>>Да вас, с такой архитектурой приговорят к пожизненному расстрелу через повешенье, однозначно!

G>А куда деваться ?

Работать надо, как это ни удивительно. А не надеяться на IT-шное словоблудство.

G>Собственно, пример был с бокситового рудника. многие тысячи точек сбора данных, сотни точек управления, в том числе много критических ( подьемники, воздухоподача, водооткачка )


Для деструктивного кода поле широчайшее, к сожалению. Шире просто представить невозможно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[17]: Нужны примеры...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.11.08 19:02
Оценка: :)
Здравствуйте, Erop, Вы писали:

E>Да вас, с такой архитектурой [...]


Вот вам и способ "выстрелить самому себе в ногу" на Эрланге, Лиспе и куче других языков. С++ в сравнении с ними — дитё розовощёкое.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[19]: NB: Ещё один момент
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.11.08 19:40
Оценка:
ГВ>А фигли? Ничего деструктивного не выполняется — это программисты во всём виноваты.

И самое главное — документы-то все в порядке. И никаких формальных нарушений — все ответственные лица ответственно выполнили свою ответственную работу с документами приёмо-сдаточных испытаний.

G>>К счастью, периферийное телемеханическое железо имеет очень ограниченный ассортимент


Если я тебя правильно понял, то это многое объясняет. Например, вам может быть позволено играться, потому что сама аппаратура обладает необходимой надёжностью по параметрам управления, а способы наблюдения (сиречь — форматирование и преобразование данных наблюдений) уже не так критичны, это всего лишь плюс-минус удобство. Правду сказать, в это мне верится гораздо больше, чем в паталогический идиотизм управленцев.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[21]: Нужны примеры...
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.11.08 04:41
Оценка: +1
Здравствуйте, gandalfgrey, Вы писали:

G>Надо заметить, что стандарты на телемеханические и телеметрические протоколы предусматривают передачу алгоритмов в качестве конфигурационных данных. Но доля истины в этом утверждении есть — конечно, тайком от заказчика делать этого никто не будет — просто ему самому спокойнее, когда бинарники работают те же самые, что и год назад.

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

Если имеется в виду то, что сервер типа не изменился; стоит начать посылать на него пакеты в старом формате — и всё починится, то я не понимаю в чем принципиальная разница с удаленной перепрошивкой. Потому что с ней "стоит перепрошить на сентябрьскую версию из SVN — и всё починится".

Зато есть некоторые опасения. Грубо говоря, смена "жесткого" протокола и связанная с ней перепрошивка — операция редкая и привилегированная. Все они лежат в логе; всегда точно известно, кто когда что и на что менял. В случае per-message изменения кода, для анализа катастрофы нужен полный лог всех сообщений.

Типа вот сорвало у нас предохранительный клапан; почему — оказывается один из пакетов в экспериментальных целях передал некий коэффициент в виде byte, а не int; после десериализации это привело к целому переполнению при умножении, и на управляемое устройство пошёл не тот сигнал.

Как ты будешь отлавливать такие ситуации? Вроде смотрим — всё нормально; в системе — ни следа от вредоносного кода; откуда взялся запредельный параметр — невозможно понять.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: Сериализация и языки
От: gandalfgrey  
Дата: 28.11.08 07:30
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>По уму тут надо менять процедуру открытия доступа через SSH. А то у вас интересно получается — физически к серверу доступа нет, а в "электронном" смысле не то что доступ есть, а просто автострада. Скорее всего, кто-то попросту закрыл глаза на какие-то пункты инструкций, использовав, например, то, что там ничего не говорилось о возможностях Erlang. А так и инструкции "соблюдены", и софт обновляется. Если бы сервер на самом деле хотели защитить, то вам не позволили бы оставлять такие "закладки" в протоколе. Ага, это чаще всего называется именно так — закладка для неконтролируемого обновления. Если ты хотел узнать про апофеоз, то вот это он и есть на самом деле.

Тут есть еще одно "НО" — а именно, рестарт системы при замене софта цивильным способом занимает много времени. Горячее обновление кода не спасает ситуацию, поскольку присутствуют и модули на Ерланге, и на С++, и на Тикле. Причем конфигурация многосерверная, что еще более замедляет подьем системы. Модуль-концентратор на С++ написан 7 лет назад, и при достаточно больших базах может стартовать несколько часов. Все это время система частично функциональна.

ГВ>Что есть частный случай известного обоим сторонам описания передаваемых данных.

Ну разумеется, в любом случае мы исходим из наших знаний о железе и процессе работы с ним. Так что можно назвать это знание ПРЕДОПРЕДЕЛЕННЫМ

ГВ>Да нет. Селява здесь в требованиях нормативных документов и технических нюансах систем программирования.

А это гораздо хуже...

ГВ>Ну опять ты за своё. Народ на самом деле жаждет на ёлку влезть... То есть он жаждет, чтобы формальные требования к процедурам соблюдались, но в то же время ПО обновлялось без особых заморочек. Менять процедуры хлопотно и лишняя ответственность, проходить их каждый раз, считай — прибить дело на корню, посему попросту обойти их — гораздо проще. Пусть даже для этого придётся назвать динамически обновляемое ПО "одной и той же версией", что может быть корректным по каким-то формальным признакам.

Вот она, сермяжно-посконная правда ! Все так и есть

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

А вот уже уже утрирование

ГВ>Короче говоря, теперь начинается сага о терминах и их трактовках в разных контекстах, только и всего. А ты пытаешься на этом основании чуть ли не фундаментальные законы информационных технологий сотрясти.

Не, даже не помышлял такого ! И чего, собственно, революционного в передаче алгоритмов по проводам ? В любом случае, расчетные скрипты являются частью файла конфигурации. А подмена конфигурации ДОЛЖНА осуществляться без полного перезапуска системы
Re[22]: Нужны примеры...
От: gandalfgrey  
Дата: 28.11.08 07:33
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вот-вот. Ключевое слово — процедура обновления. Сопряжённые термины: ответственность, делегирование, полномочия, допуск.

Не пробовали сказать такие слова какому-либо мелкому/среднему боссу в большой корпорации ? Кивать с умным видом они, конечно, будут — но это и все !

ГВ>Да, да, да. Ему самому спокойнее, даже если эти бинарники уже отодвинуты в дальний угол.

Ежели говорить формально — то бинарники те же, что и были.

ГВ>Зловеще выглядит "подгрузка исполняемого кода". А интерпертируемые скрипты — не страшно. Они ж интерпретируемые — чего их бояться-то?!

Скрипты проще ограничить в возможностях.
Re[21]: Нужны примеры...
От: gandalfgrey  
Дата: 28.11.08 07:39
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Оригиналы они, эти дядьки-КИПовцы. То есть они могут привести устройство в нерабочее состояние, так, что ли?

Запросто ! И не раз такое делали. Вот пример : есть такой агрегат, аппаратный концентратор УСПД. Работает крайне криво, но изготовители как бы работают над этим. Присылают новые прошивки и т.д. Но ! Эти прошивки работают корректно только на определенных модификациях агрегата. Определить это можно только разглядывая печатную плату.

ГВ>Ну и что? Ничего же из ниоткуда не берётся, так или иначе — сначала устаканивается сам формат данных, а прежде оного устканства появляется требование.

Господя ! Если б это было так ! Сначала требование, причем из разряда "вынь да положь"

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

В большинстве случаев — значительную часть данных высчитывает микросервер, на котором висит этот прибор.
Re[19]: Нужны примеры...
От: gandalfgrey  
Дата: 28.11.08 07:49
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Деструктивный — это вовсе не тот, который приводит к core dump. Вернее — не только он. Например, деструктивный код может фальсифицировать данные о температуре прибора, из-за чего этот прибор будет неправильно охлаждаться. Из прибора пойдёт дым, или он покроется инеем, или выдаст кривую команду на управляющие системы. Но при этом всё пройдёт тихо и гладко с точки зрения ОС — даже мусоросборщик отработает. Так что core dump — это так, страшилка для кулхацкеров.

Согласен.

ГВ>Так вот, то, что вам дают возможность апдейтить код, как вам вздумается (сиречь — по упрощённой процедуре) — это означает, что ответственные лица в организации-заказчике снимают (частично) с себя ответственность за подобные последствия. А фигли? Ничего деструктивного не выполняется — это программисты во всём виноваты. И вместо того, чтобы развивать содержательную часть приёмо-сдаточных испытаний — переваливают ответственность за последствия полностью на вас.

Неа — ответственность лежит всегда и только на диспетчерах. Только человек может оценить ситуацию и принять решение. Например, расходомер стока воды показывает, что поток резко убыл. А потребляемая мощность автономного насоса каскадом ниже увеличилась. И что делать, эвакуировать людей с горизонта или поставить расходомер в план ремонта ?

ГВ>Оригинальненько так: Let them crash, особенно в контексте того, о чём ты написал ниже.

Это имеет значение "пусть лучше оно сдохнет, чем неправильно отработает"

ГВ>Работать надо, как это ни удивительно. А не надеяться на IT-шное словоблудство.

Именно, что работать. А не заниматься беспрестанными приемо-сдачами. Словоблудство никому не нужно. А нужна людям работа оборудования, непрерывная, без остановок на наладку / конфигурирование.

ГВ>Для деструктивного кода поле широчайшее, к сожалению. Шире просто представить невозможно.

Это должен быть ПРЕДНАМЕРЕННО вредоносный код
Re[18]: Нужны примеры...
От: gandalfgrey  
Дата: 28.11.08 07:52
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вот вам и способ "выстрелить самому себе в ногу" на Эрланге, Лиспе и куче других языков. С++ в сравнении с ними — дитё розовощёкое.

Жизнь показывает иное — ежели падения или отказы ( по причине некорректности кода / входных данных / чего-то еще ) модулей на С++ случаются регулярно, то Ерланговские минисервера работают. Они просто работают. Годами.
Статистика на этот счет у меня богатая, так что переубедить меня будет сложно.
Re[20]: NB: Ещё один момент
От: gandalfgrey  
Дата: 28.11.08 07:58
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>И самое главное — документы-то все в порядке. И никаких формальных нарушений — все ответственные лица ответственно выполнили свою ответственную работу с документами приёмо-сдаточных испытаний.

Доля истины в этом есть, но только доля. Бумага и вправду прикрывает задницу, но это непрочный щит. И в случае затопления горизонта иметь будут всех, мало обращая внимания на бумажки. Потому как — денежные потери это удар по карману владельцев и топов

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

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