Электростальский форум
Hi-Tech => Компьютеры, периферия, мультимедиа и ПО => Тема начата: exBoMBeR от 27.02.08, 16:29:43
-
А.Г. Полетыкин, Е.Ф. Жарко, И.Н. Зуенкова, В.Г. Промыслов, М.Е. Бывайков, Н.Э. Менгазетдинов
Обеспечение технологической независимости, лицензионной чистоты и безопасности программного обеспечения в атомной энергетике
Аннотация
В статье рассматриваются вопросы обеспечения технологической независимости, лицензионной чистоты и безопасности, возникающие при применении программного обеспечения в АСУ ТП АЭС. Исследуются виды зависимости, источники опасности и излагается точка зрения Института проблем управления им. В.А. Трапезникова РАН на решение этих вопросов.
Введение
Программное обеспечение (ПО) стало одной из составляющих окружающей среды. Оно работает в мобильных телефонах, домашних компьютерах, в магазинах, медицинских учреждениях, предприятиях, на транспорте, в системах жизнеобеспечения, в системах, важных для безопасности, включая ядерную.
Нужно отметить, что во многих случаях используется одно и то же программное обеспечение. Ярким примером является операционная система Windows фирмы Microsoft, применяемая широким спектром пользователей: от игровых залов до третьего энергоблока Калининской АЭС.
В данной статье изложена официальная точка зрения Института проблем управления им. В.А. Трапезникова РАН на обеспечение технологической независимости, лицензионной чистоты, качества и безопасности ПО в атомной энергетике.
1. Технологическая независимость и лицензионная чистота
Технологическая зависимость организации А от организации Б возникает при наступлении одного из следующих случаев.
(1) А использует ПО, произведенное Б, но Б не передает А исходные коды ПО;
(2) Б передает исполняемые и исходные коды ПО А, но не производит обучение персонала А в объеме, необходимом для внесения изменений и доработок в ПО;
(3) Б передает исполняемые и исходные коды ПО А, по возможности обучает персонал А правилам внесения изменений и доработок в ПО, но оставляет за собой через лицензионные соглашения права собственности на ПО, которые позволяют Б контролировать применение ПО.
Случай (1) типичен при применении операционных систем ведущих мировых производителей, SCADA-систем и т. п. Это ? худшая из всех видов зависимостей. В этом случае пользователь ПО зависит о прихотей производителей, которые по своему усмотрению могут менять ПО, что вынуждает пользователей нести значительные расходы по адаптации нового ПО, его испытаниям и т. п. Кроме этого, при использовании продукции иностранных поставщиков зависимость типа (1) может существенно ограничить применение конечного продукта, в котором используется ПО, например из-за эмбарго, политических, конкурентных и других причин.
Случай (2) имеет место при использовании ПО "с открытым кодом". К ним, в частности, относятся версии операционных систем LINUX, компиляторы, Web-броузеры, утилиты и т.п.
В этом случае пользователь имеет возможность получить независимость. Но для этого ему нужно создать группу, лабораторию или целый институт, набрать в него квалифицированных специалистов, которые способны разобраться в исходных кодах ПО и содержать их в течение всего времени эксплуатации данного ПО.
Это требует значительных финансовых затрат и под силу либо государству в целом, либо отрасли (Министерство обороны, РОСАТОМ, Академия наук), либо крупной корпорации (РАО ЕЭС, Газпром и т. п.).
Случай (3) ? это лицензионная зависимость. Часто она наступает при применении ПО "с открытым кодом", произведенным фирмами США и других стран. Примером может служить продукт Open Office фирмы Sun, который будучи продукцией США не может поставляться в ряд стран и организаций. В этом случае определенная зависимость от фирмы или иностранного государства не может быть устранена полностью, а конечный продукт не будет лицензионно чистым.
Если понимать под А отечественные фирмы ? строители АЭС (Атомстройэкспорт, Росэнергоатом), то как им обеспечить технологическую независимость и лицензионную чистоту своей конечной продукции ? энергоблоков АЭС ? от иностранных фирм-изготовителей ПО и политики чужих государств.
Есть только два пути. Первый ? заказывать ПО в России либо у подконтрольных заказчику фирм, либо у государственных организаций, недосягаемых для недружественных действий. К ним относятся федеральные государственные унитарные предприятия РОСАТОМа, институты РАН, федеральные ядерные центры и другие отечественные организации.
Второй путь связан с преодолением зависимости типов (2) и, частично (3). Это можно сделать либо указанным выше способом, либо путем установления контроля над фирмой-поставщиком ПО.
2. Безопасность ПО
Безопасное ПО ? это ПО, выполняющее только возложенные на него владельцем задачи и не выполняющее никаких других.
Для того, чтобы проверить выполнение требуемых задач проводятся испытания.
Однако, выполняет ли ПО другие, непредусмотренные законным владельцем задачи, испытаниями проверить нельзя.
Например, как можно проверить отсутствие закладки в операционной системе, которая содержит суперпароль для входа в систему? Для программиста ответ очевиден: нужно проанализировать исходный код ПО. Иного пути нет.
Иными словами, ПО должно быть подвергнуть операции верификации исходного кода и документации.
Вообще говоря, это утверждение носит характер аксиомы для всех, кто занимается ПО для АЭС, поскольку оно содержится в нормативных документах [ ].
Однако на практике это требование часто нарушается. Так, на третьем блоке Калининской АЭС в системе верхнего блочного уровня (системе, важной для ядерной безопасности) используются операционные системы MS Windows и Open WMS, верификацию исходного кода которых никто не проводил. То есть, используется иностранное ПО, безопасность которого не подтверждена.
Мы считаем, что практика применения на АЭС ПО сомнительной безопасности должна быть законодательно запрещена, а само ПО заменено.
Какая бы фирма, российская или зарубежная, ни разрабатывала ПО для АЭС, процедура его изготовления должна производиться по методам, обеспечивающим качество и безопасность.
3. Заключение
ИПУ РАН является одним из ведущих российских разработчиков технологий и ПО для АСУ ТП АЭС.
В частности, системы верхнего блочного уровня (СВБУ), разрабатываемые в России, базируются не технических решениях, предложенных ИПУ РАН.
ИПУ РАН является разработчиком СВБУ для АЭС "Бушер"(Иран) и поставщиком ПО для АЭС "Куданкулам" (Индия), а также поставляет компоненты ПО и системы на отечественные ядерные установки.
ПО ИПУ РАН, в частности, включает в себя операционную систему, построенную на основе ПО "с открытым кодом", SCADA-систему и другие продукты собственного производства. Более подробная информация представлена в отдельной статье, входящей в данный номер журнала.
-
НЕКОТОРЫЕ АСПЕКТЫ ПРИМЕНЕНИЯ СВОБОДНО РАСПРОСТРАНЯЕМЫХ
ПРОГРАММНЫХ ПРОДУКТОВ В АСУ ТП АЭС
А.В. Антонов, А.А. Байбулатов, С.И. Масолкин, А.Г. Полетыкин, К.В. Семенков
Анализируются вопросы применения свободно распространяемых программных продуктов в
АСУ ТП АЭС. Рассмотрены связанные с этим проблемы и приведены рекомендации по их решению.
1 Введение
Значительное повышение сложности современных комплексов программ, используемых в АСУ
ТП в атомной энергетике, привело к осознанию того, что одному предприятию-разработчику
невозможно, а часто и нецелесообразно создавать весь комплекс программ самостоятельно. В последнее
время возник принципиально новый подход: применение в комплексах программ уже существующих
свободно распространяемых программных продуктов. Использование таких программных продуктов в
отечественных АСУ ТП АЭС, поставляемых в третьи страны, ? является, по-видимому, единственно
приемлемым решением, но при этом возникают некоторые трудности, обзору которых посвящена
статья.
2 Необходимость применения свободно распространяемых программных продуктов в АСУ ТП
На современном этапе развития промышленного производства невозможно обойтись без
широкого применения автоматизированных систем управления технологическими процессами (АСУ
ТП).
Неуклонное возрастание единичной производительности агрегатов практически во всех отраслях
промышленности (например, мощность создаваемых энергоблоков электростанций превзошла 1 млн.
кВт) приводит соответственно к интенсивному росту необходимой ?мощности? применяемых систем
контроля и управления. Изменяются взгляды на значение энергетических ресурсов, экономию топлива,
роль человека в производстве и на защиту окружающей среды; в результате происходит существенное
повышение требований к качеству ведения технологических процессов. Происходит естественный
процесс вовлечения все новых и новых агрегатов и участков в сферу действия централизованного
управления.
Отмеченные выше тенденции приводят к резкому повышению сложности АСУ ТП,
используемых в настоящее время в промышленности. И это усложнение затрагивает не только
технические средства, но и программные. Программные средства АСУ ТП ? это сложные комплексы
программ (КП), состоящие из многих программных компонентов. В создании и производстве различных
комплексов программ участвуют сотни тысяч специалистов, и их количество непрерывно
увеличивается. Затраты на создание и внедрение программ из года в год быстро возрастают.
Отечественный и зарубежный опыт обобщения оценок конкретных разработок подтверждает, что
интегральные ежегодные затраты на аппаратуру ЭВМ и программные средства соизмеримы [1].
Создание "с нуля" сложного КП для применения в АСУ ТП требует значительных финансовых и
временных затрат. Поэтому одному предприятию-разработчику с этой задачей не справиться. Решить
данную задачу можно, если рассматривать КП как совокупность отдельных взаимосвязанных
программных компонентов. Часть компонентов предприятие-разработчик создает самостоятельно. Что
касается оставшихся компонентов, то существует два подхода: закупка лицензионно-чистых
программных продуктов, поддерживаемых гарантированным сопровождением конкретных фирм-
поставщиков, или приобретение свободно распространяемых программных компонентов. Лицензионно-
чистые программные продукты сопровождаются полной эксплуатационной и технической
документацией, сертификатом соответствия и комплектами тестов. В контрактах на закупку
фиксируются обязательства поставщиков по длительному сопровождению и замене версий программ
при выявлении дефектов или совершенствовании функций. Для применений, требующих высокой
надежности программных компонентов в АСУ ТП, часто предлагается этот подход. Однако он обладает
следующими недостатками. Во-первых, коммерческие программные продукты довольно дороги, и
затраты на их приобретение сопоставимы с затратами на их самостоятельную разработку. Во-вторых, и
это самое главное, на коммерческие продукты существуют лицензионные ограничения на поставку.
Следовательно, созданные с их использованием КП нельзя поставлять в некоторые третьи страны. В
этом случае единственное решение ? это использование свободно распространяемых программных
компонентов. Свободно распространяемые программные компоненты являются разновидностью
программных компонентов, получаемых в готовом виде (pre-existing software ?components ? PSW) с
исходным кодом. Далее под PSW-компонентами будем понимать именно свободно распространяемые
готовые программные продукты.
3 Проблемы применения свободно распространяемых компонентов
PSW-компоненты часто используются во многих приложениях. На основе значительного опыта
по их эксплуатации в каждой конкретной области применения происходит постоянное
совершенствование этих программных продуктов. Поэтому можно предположить, что многие PSW-
компоненты достаточно высокого качества. Но, не смотря на это, при использовании свободно
распространяемых PSW-компонентов возникают некоторые проблемы [2].
1. Функциональные и другие характеристики (надежность, производительность) PSW-компонентов
часто нечетко определены и документированы.
2. Документация и данные по эксплуатации PSW-компонентов часто неадекватно представлены, и они
не могут компенсировать отсутствие ясного представления о продукте и процессе его создания.
3. Как следствие вышеуказанных проблем, в процессе приемки программного продукта трудно
оценить, в какой степени PSW-компонент соответствует спецификациям разрабатываемого приложения.
4. Опыт, приобретенный в ходе эксплуатации PSW-компонентов, может свидетельствовать о неполном
функциональном соответствии компонентов разрабатываемому приложению. Следовательно, поведение
программного обеспечения может иметь непредсказуемые характеристики.
-
4 Некоторые подходы к решению проблем
Для решения вышеизложенных проблем можно применять следующие рекомендации.
1. Функции, реализуемые PSW-компонентами, должны быть четко определены, и их влияние на
безопасность системы должно быть оценено.
2. PSW-компоненты, которые будут использоваться, должны быть точно определены, включая их
версию.
3. Интерфейсы, через которые пользователь или другое программное обеспечение вызывает PSW-
модули, должны быть четко описаны и всесторонне протестированы. Должно быть представлено
доказательство того, что никакая (и случайная в том числе) непредусмотренная последовательность
входных событий не может вызвать непреднамеренно данные модули.
4. PSW-компонент должен поддерживаться в соответствие с традициями хорошего программирования
и со стандартами качества, адекватными предполагаемому использованию продукта.
5. При использовании в системах безопасности PSW-компонент должен быть подвергнут
тестированию в качестве конечного продукта с такой же тщательностью как любое новое программное
обеспечение. В случае необходимости, должен быть выполнен процесс обратной инженерии с тем,
чтобы можно было выявить полную спецификацию PSW-компонента.
6. Должны быть доступны документация о дизайне PSW-компонента и его исходные коды с тем, чтобы
при необходимости можно было выполнить модификацию PSW-компонента.
7. Должна быть доступна информация, необходимая для оценки качества PSW-компонента, его
коммерческой ценности и трудозатрат по его поддержанию; этой информации должно быть достаточно
для правильной оценки PSW с учетом требуемого уровня качества.
8. При приемо-сдаточном тестировании должны быть выполнены следующие действия:
1) функции, реализуемые PSW-компонентом, должны соответствовать всем спецификациям,
сформулированным в требованиях по безопасности системы, а также спецификациям других
использованных прикладных программных приложений;
2) функции PSW-компонента, не требуемые спецификациями по безопасности системы, не должны
быть задействованы и отрицательно повлиять на возможность реализации функций, указанных в
спецификации, например через ошибочный ввод данных, прерывания или неправильное
использование компонента;
3) должен быть выполнен анализ соответствия проектного решения PSW-компонента требованиям
стандартов применимости программных продуктов;
4) функции PSW-компонента, предназначенные для использования, должны быть проверены
тестированием. Испытания могут также включать тесты, выполненные поставщиком;
5) должен быть выполнен анализ того, что функции PSW-компонента не могут использоваться
системой безопасности, другой программой или пользователями никаким способом, отличным от
определенных в спецификации и соответствующим образом протестированным (в случае
необходимости, это может быть сделано при реализации специально оговоренных условий)
9. Если доступна достаточная информация о предыдущем опыте эксплуатации PSW-компонента, то
опыт подобной эксплуатации должен быть подробно задокументирован с учетом продолжительности
использования PSW-компонента, сообщений об ошибках и истории выпуска различных версий
продукта. При этом должна использоваться последняя версия продукта за исключением случаев, когда
речь идет о работе тех частей продукта, которые не подвергались изменениям в последней версии.
10. Если имеющихся данных, указанных в рекомендации 9 недостаточно, тогда должен быть выполнен
анализ (оценка риска) влияния отказов PSW-компонента на безопасность системы. Особое внимание
должно быть уделено побочным эффектам и сбоям, которые могут проявиться на уровнях интерфейсов
между PSW-компонента и пользователем и/или другими программными компонентами.
11. Ошибки, выявленные в процессе тестирования PSW-копонента, должны быть проанализированы и
учтены в ходе приемо-сдаточных испытаний.
В качестве примера применения свободно распространяемых программных продуктов можно
привести использование операционной системы (ОС) Linux в верхнем уровне АСУ ТП АЭС. ОС Linux ?
это оптимальный выбор для тех КП, которые поставляются в третьи страны. В этом случае
использование таких коммерческих операционных систем, как HP-UX, SCO, Solaris невозможно в силу
лицензионных ограничений на поставку.
ОС Linux как программный продукт, получаемый в ?готовом виде?, удовлетворяет следующим
требованиям:
1. Не имеет лицензионных ограничений на поставку.
2. Удовлетворяет требованиям, изложенным в техническом задании на систему управления верхнего
уровне АСУ ТП АЭС.
3. Имеет возможность для модификации, верификации, обслуживания и сопровождения.
4. Имеет поддержку основных производителей технических средств и программного обеспечения.
5 Заключение
Повторно используемые программные компоненты, созданные сторонними разработчиками для
своих целей, могут достигать высокого качества. Поэтому их целесообразно включать в комплексы
программ АСУ ТП АЭС, требующих высокой надежности и безопасности функционирования. Но для
этого необходимо проводить необходимую доработку.
СПИСОК ЛИТЕРАТУРЫ
1. Липаев В. В., Потапов А. И. Оценка затрат на разработку программных средств. ? М.:
Финансы и статистика, 1988. ? 224 с.
2. Доклад Европейской Комиссии ?Современные требования и практика лицензирования критически
важных программных средств ядерной контрольной аппаратуры для обеспечения безопасности",
раздел 1.3 (доклад EUR 18158 EN, проект, версия 8, ISSN 1018-5593, 1998, находится в Центре
официальных публикаций Европейского Союза (Office for Official Publications of the European
Communities, L-2985 Luxembourg)).
-
Линуксойд, вы кому пытаетесь втереть, что кто-то там верифицировал линукс ? Чиновникам втирайте. Им что линукс что свинукс что исходный код что конституция США. А сюда-то зачем постить это ? Этих "верификаторов" и "поставщиков" ткни в любую строчку ядра линукс. Они даже приблизительно не скажут, что она делает. Как они могут его сопровождать ? Как могут модифицировать ? Они же безграмотны. В России нет разработки. Нет. И серьёзных программистов нет. Да даже если бы они были. Это просто смешно браться за поддержку такого мощного продукта, не имея связи с ведущими разработчиками. Не понимать таких вещей - это надо быть весьма некомпетентым человеком. Наша контора занимается верификацией в том числе. Верифицировать линукс ? Вам любой засмеется в лицо.
Хотите привести пример внедрения линукса ? Так это. Оно какбы не внедрение. Станция-то того. Не работаетЪ. До сих пор надеетесь, что Бушерская станция будет пущена ? Она никогда не будет пущена. А если будет пущена, то только когда вернутся немцы и сделают всё, как надо.
-
Стало интересно, а что за немцы? :)
-
те, которые до нас эту станцию почти достроили.
-
Линуксойд, вы кому пытаетесь втереть, что кто-то там верифицировал линукс ?
Судя по вашему посту вы не правильно выбрали ник ... вы уважаемый не Нервный ... вы, извините, Тупой
Во первых:
Я НЕ ЛИНУКСОИД!!!
Во вторых:
Я НЕ ВТИРАЮ, А ЦИТИРУЮ ОФИЦИАЛЬНЫЙ ДОКУМЕНТ ВЕДУЩЕГО РОССИЙСКОГО ИНСТИТУТА
До сих пор надеетесь, что Бушерская станция будет пущена ? Она никогда не будет пущена.
Может вы не в курсе, но туда уже два месяца как топливо поставили ... монтажные работы практически завершены, летом начнется обучение персонала, к концу года начнутся плановые пуски реактора.
В декабре в Н.Новгороде прошел первый этап приемосдаточных испытаний ПТК АЭС Куданкулам (Индия), которая кстати строится по тому же проекту что и АЭС в Бушере. Я на них лично присутствовал ...
Может скажете что и в Индии АЭС никогда не будет достроена???
P.S.
Гы ... я вашу шутку про немцев кому нить из АСЭ (Атомстройэкспорт) расскажу ... пусть поржут ... а то у нас ни Путин, ни Медведев, ни даже Кириенко не знают что у нас будет достроено, а что нет ... судя по всему только Нервный это знает ...
-
индийский реактор будет пущен. потому что стоят его индусы сами, а кириенковская контора туда только сливает технологии, наработанные в СССР. бушер же строили сами знаете кто. а топливо. его на пятый блок курска поставили двадцать лет назад. так и валяется.
-
> Я НЕ ВТИРАЮ, А ЦИТИРУЮ ОФИЦИАЛЬНЫЙ ДОКУМЕНТ ВЕДУЩЕГО РОССИЙСКОГО ИНСТИТУТА
а зачем вы его цитируете-то ? и для кого ? то, что на бушер будут ставить линупс, я знал года три назад. ЕДИНСТВЕННАЯ причина - эмбарго США. ничего более просто нельзя поставить. а весь остальной бред - отмазка для чиновникоа. ведущий институт. видел я представителей этого ведущего.
-
индийский реактор будет пущен. потому что стоят его индусы сами ...
Да ничего они сами не строят ... индусы сами пока еще даже кирпичи не изобрели ... АСУ ТП например делается на НИИИС-е в Н.Новгороде.
... то, что на бушер будут ставить линупс, я знал года три назад. ЕДИНСТВЕННАЯ причина - эмбарго США. ничего более просто нельзя поставить.
...
Судя по всему на Индию эмбарго США тоже распространяется? Там ставится система - точная копия Иранской.
Я сам неоднократно высказывал свое негативное мнение по поводу использования Linux ... но увы ... таковы реалии - все АЭС, которые строятся или будут строиться в обозримом будующем в третьих странах будут работать под управлением Linux ... не смотря на все его недостатки.
Более того ... я почти уверен что люди из ИПУ РАН добьются того что и на отечественных станциях будут ставить Linux.
-
> Гы ... я вашу шутку про немцев кому нить из АСЭ (Атомстройэкспорт) расскажу ... пусть поржут ... а то у нас ни Путин, ни Медведев, ни даже Кириенко не знают что у нас будет достроено, а что нет ... судя по всему только Нервный это знает ...
Расскажите-расскажите. Был тут один отец, рвавший на себе волосы, что Бушер пустят в феврале. Прошлого года. Время вылечит и Вас. Что касается Кириенко, то ему сливать не впервой.
> Да ничего они сами не строят ... индусы сами пока еще даже кирпичи не изобрели ...
Индусы - очень умные, образованные и требовательные люди. Я с очень большим трудом представляю, как наши "спецы" могут там работать. Зачморят ведь.
> Судя по всему на Индию эмбарго США тоже распространяется?
Судя по всему, распространяется. Поэтому, скороее всего, там будет линукс. Даже возможно, поначалу эта подделка на мотифе. Но рано или поздно, скорее первое, это убожище оттуда выкинут ссаными тряпками.
> Более того ... я почти уверен что люди из ИПУ РАН добьются того что и на отечественных станциях будут ставить Linux.
На отчественных станциях будут ставить Microsoft Windows. И ИПУ РАН тут совершенно непричём. Эти деятели сами себе противоречат. Сначала совершенно справедливо замечают, что "Cлучай (2) имеет место при использовании ПО "с открытым кодом". К ним, в частности, относятся версии операционных систем LINUX", далее идёт словесный понос, который читать противно, а вывод из всего делают, что Линукс их устраивает. Ну конечно, ещё бы. Патч, исправляющий превышение полномочий до суперпользователя, уже наложили ? Вряд-ли.
-
Много времени назад я бы был в командировке в Иркутске. Они делали кассовые аппараты и столкнулись с проблемами лицензионного характера в том числе. Они взяли и переписали BIOS и DOS. Не полностью конечно же, но в объёме, необходимом для запуска откомилированных на стандартном компилятре программ. Делали это 3 человека. Три. Вот где выход. Вот что реально, поддаётся верификации, можно полноценно сопровождать. Вот где интересная работа. Можно даже сказать, наука. Сам на такую побежал бы, если бы позвали. А не грёбаный ляликс плюс прикладуха-страхолюдина из прошлого века. Невежы. И их ещё выведут на чистую воду.
-
Нервный, а ты индусский код видел когда нить? :) Если нет, то погляди, мне кажется твое мнение изменится. А если видел, то уж не знаю, как у тебя язык поворачивается.
-
Нервный, а ты индусский код видел когда нить? :) Если нет, то погляди, мне кажется твое мнение изменится. А если видел, то уж не знаю, как у тебя язык поворачивается.
Индия - мировой лидер офшора. Российских программных продуктов вообще нет. Почаще обращайтесь к результату, может, научитесь отличать истиные идеалы от ложных. Мой код тоже не образцовый. Когда идёт реальная работа. Работа на время. Просто нет возможности сделать красиво. Да и не надо это. Нашлись судьи. Попробуйте реализовать такой объём. По-другому запоёте.
-
...
Вот где интересная работа. Можно даже сказать, наука. Сам на такую побежал бы, если бы позвали.
...
Скажите, а как вы относитесь к таким проектам как FreeDOS? ... лицензионно чисто ... полностью открыто ...
Кстати, насколько мне известно, тот же ИПУ РАН поставляет в Иран в составе ПТК СВБУ Бушер несколько машин работающих под управлением IBM PCDOS ... в Индию тоже ...
-
Кстати, сейчас сотрудничаю с одной не маленькой конторой. Так вот там довольно много програмистов из Индии трудятся. Работают удаленно. Сначала удивился, неужели своих не нашли, чтобы в офис могли ездить. Выходит нанять удаленно человека из Индии проще и надежнее, чем доморощенных "спецов".
Про Кириенко... Для меня вообще было шоком, когда он был назначен на его теперешнюю должность... Что он может понимать в атомной энергии?
-
да Индусы скоро захватят весь программерский мир...
и самая фишка что у них монополия на свои разработки - честно, разобраться в них могут только сами индусы
а по теме... свободное ПО, помоему глупо ставить на такие ответственные проекты... т.к. в такого рода ПО четко прописано "ВЫ ИСПОЛЬЗУЕТЕ ЭТОТ ПРОГРАМНЫЙ ПРОДУкТ НА СВОЙ СТРАХ И РИСК", если что - ни на кого потом не свалишь ответственность...
-
Ну в чужом коде всегда трудно разбираться... Не знаю ни одного программиста, который бы любил разбираться в чужих кодах... Он лучше свой напишет... Может это проблема образования? Не знаю, стандарты какие-нибудь должны быть... А то получается, написал, и после тебя хоть потоп...
> а по теме... свободное ПО, помоему глупо ставить на такие ответственные проекты... т.к. в такого рода ПО четко прописано "ВЫ ИСПОЛЬЗУЕТЕ ЭТОТ ПРОГРАМНЫЙ ПРОДУкТ НА СВОЙ СТРАХ И РИСК", если что - ни на кого потом не свалишь ответственность...
Нервный уже говорил, что туда просто запрещен ввоз продукции от Microsoft...
-
что в мире только Linux и Windows?
а насчет кода.. незнаю.. в ПО своего начальника (американца) я разбираюсь нормально.. и читаю вполне легко
правда вот в пример - софтина над которой я работал на своей предыдущей работе (Rockerzz знает, видел)... писал ее русский программист, МГУшник... но там пипец.. черт ногу сломит... я разбирался в этом говне недели две точно... собственно основной косяк был нвыерное в том, что прога была написана не объектно-ориентировано... вобщем всЁ в кучу... названия функций даже отдаленно не объясняли своей функциональности... слава богу была хоть какая-то логика в распределении этих самых функци по файлам библиотек...
но собственно говоря все от торопливости.. я лично считаю, что лучше не сильно торопиться, но писать красиво, чтобы потом через 2 года не приходилось это все с нуля переписывать...
-
> Нервный уже говорил, что туда просто запрещен ввоз продукции от Microsoft...
Вот уже оказывается чего я "говорил". А какже её туда ввезли ?
-
> Нервный уже говорил, что туда просто запрещен ввоз продукции от Microsoft...
Вот уже оказывается чего я "говорил". А какже её туда ввезли ?
Вы же сами это сказали:
то, что на бушер будут ставить линупс, я знал года три назад. ЕДИНСТВЕННАЯ причина - эмбарго США.
Именно поэтому я так и сказал... Именно это имел в виду... Ничего больше...
-
а по теме... свободное ПО, помоему глупо ставить на такие ответственные проекты... т.к. в такого рода ПО четко прописано "ВЫ ИСПОЛЬЗУЕТЕ ЭТОТ ПРОГРАМНЫЙ ПРОДУкТ НА СВОЙ СТРАХ И РИСК", если что - ни на кого потом не свалишь ответственность...
Почитайте внимательно лицензионное соглашение на Microsoft Windows ... хотя бы раз в жизни сделайте это - узнаете много нового.
Или вы наивно полагаете что продав вам закрытое коммерчесоке ПО какая то компания захочет нести ответственность за последствия его применения? или станет вам что то гарантировать???
-
Кстати ... специально не поленился слазить на сайт Microsoft:
Microsoft Windows XP Professional
ЛИЦЕНЗИОННОЕ СОГЛАШЕНИЕ
http://www.microsoft.com/Rus/Licensing/General/examples/winxppro_box.mspx (http://www.microsoft.com/Rus/Licensing/General/examples/winxppro_box.mspx)
...
11. ОТКАЗ ОТ ПРЕДОСТАВЛЕНИЯ ГАРАНТИЙ.
Упомянутая ниже ограниченная гарантия является единственной предоставляемой вам явной гарантией, заменяющей любые другие явные гарантии (если таковые имелись), приведенные в какой-либо документации, на упаковке или предоставленные иным образом. За исключением данной ограниченной гарантии и в наибольшей степени, разрешенной применимым законодательством, корпорация Майкрософт и ее поставщики предоставляют продукт и (если таковые предоставляются) услуги по технической поддержке на условиях ?КАК ЕСТЬ?, СО ВСЕМИ НЕИСПРАВНОСТЯМИ, и отказываются от предоставления каких-либо других явных, подразумеваемых или предусмотренных законодательством гарантий и условий, включая (но не ограничиваясь только ими) отказ от подразумеваемой гарантии, обязательств или условий пригодности для продажи и применимости для определенной цели, надежности или доступности, точности или полноты ответов или результатов работы, гарантии высокого качества исполнения, отсутствия вирусов, отсутствия небрежности при изготовлении продукта, а также предоставления или непредоставления технической поддержки или иных услуг, сведений, программного обеспечения и содержимого в результате или в связи с использованием продукта. КРОМЕ ТОГО, ПО ОТНОШЕНИЮ К ДАННОМУ ПРОДУКТУ НЕ ОБУСЛАВЛИВАЮТСЯ И НЕ ПРЕДОСТАВЛЯЮТСЯ ГАРАНТИИ ПРАВА СОБСТВЕННОСТИ, СПОКОЙНОГО ВЛАДЕНИЯ И ПОЛЬЗОВАНИЯ, СООТВЕТСТВИЯ ОПИСАНИЮ ИЛИ НЕНАРУШЕНИЯ ПРАВ НА ИНТЕЛЛЕКТУАЛЬНУЮ СОБСТВЕННОСТЬ.
12.ИСКЛЮЧЕНИЕ СЛУЧАЙНОГО, КОСВЕННОГО И ИНЫХ ОПРЕДЕЛЕННЫХ ВИДОВ УЩЕРБА.
В НАИБОЛЬШЕЙ СТЕПЕНИ, ДОПУСКАЕМОЙ ПРИМЕНИМЫМ ЗАКОНОДАТЕЛЬСТВОМ, НИ ПРИ КАКИХ ОБСТОЯТЕЛЬСТВАХ КОРПОРАЦИЯ МАЙКРОСОФТ И ЕЕ ПОСТАВЩИКИ НЕ НЕСУТ ОТВЕТСТВЕННОСТЬ ЗА КАКОЙ-ЛИБО ОСОБЫЙ ИЛИ СЛУЧАЙНЫЙ УЩЕРБ, ШТРАФНЫЕ УБЫТКИ, КОСВЕННЫЙ ИЛИ ОПОСРЕДОВАННЫЙ УЩЕРБ ИЛИ УБЫТКИ (ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯСЬ ТОЛЬКО ПЕРЕЧИСЛЕННЫМ, УПУЩЕННУЮ ВЫГОДУ, УТРАТУ КОНФИДЕНЦИАЛЬНОЙ ИЛИ ИНОЙ ИНФОРМАЦИИ, УБЫТКИ, ВЫЗВАННЫЕ ПЕРЕРЫВАМИ В КОММЕРЧЕСКОЙ ИЛИ ПРОИЗВОДСТВЕННОЙ ДЕЯТЕЛЬНОСТИ, НАНЕСЕНИЕ УЩЕРБА ЗДОРОВЬЮ, НАРУШЕНИЕ НЕПРИКОСНОВЕННОСТИ ЧАСТНОЙ ЖИЗНИ, НЕИСПОЛНЕНИЕ ЛЮБОГО ОБЯЗАТЕЛЬСТВА, ВКЛЮЧАЯ ОБЯЗАТЕЛЬСТВО ДЕЙСТВОВАТЬ ДОБРОСОВЕСТНО И С РАЗУМНОЙ ОСМОТРИТЕЛЬНОСТЬЮ, УБЫТКИ, ВЫЗВАННЫЕ НЕБРЕЖНОСТЬЮ, ЛЮБОЙ ИНОЙ УЩЕРБ И ПРОЧИЕ УБЫТКИ ИМУЩЕСТВЕННОГО ИЛИ ИНОГО ХАРАКТЕРА), ВОЗНИКАЮЩИЕ В СВЯЗИ С ИСПОЛЬЗОВАНИЕМ ИЛИ НЕВОЗМОЖНОСТЬЮ ИСПОЛЬЗОВАНИЯ ПРОДУКТА, ИЛИ ПРЕДОСТАВЛЕНИЕМ ИЛИ НЕПРЕДОСТАВЛЕНИЕМ УСЛУГ ПО ПОДДЕРЖКЕ ИЛИ ИНЫХ УСЛУГ, СВЕДЕНИЙ, ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ И СОДЕРЖИМОГО В РЕЗУЛЬТАТЕ ИЛИ В СВЯЗИ С ИСПОЛЬЗОВАНИЕМ ПРОДУКТА, ИЛИ В ИНЫХ СЛУЧАЯХ, ПРЕДУСМОТРЕННЫХ ИЛИ СВЯЗАННЫХ С ПОЛОЖЕНИЯМИ ДАННОГО ЛИЦЕНЗИОННОГО СОГЛАШЕНИЯ, ДАЖЕ В СЛУЧАЕ ВИНЫ, ГРАЖДАНСКОГО ПРАВОНАРУШЕНИЯ (ВКЛЮЧАЯ НЕБРЕЖНОСТЬ), СТРОГОЙ ОТВЕТСТВЕННОСТИ, НАРУШЕНИЯ КОРПОРАЦИЕЙ МАЙКРОСОФТ ИЛИ ЕЕ ПОСТАВЩИКАМИ ДОГОВОРНЫХ ИЛИ ГАРАНТИЙНЫХ ОБЯЗАТЕЛЬСТВ, ДАЖЕ ЕСЛИ КОРПОРАЦИЯ МАЙКРОСОФТ ИЛИ ЕЕ ПОСТАВЩИКИ БЫЛИ ЗАРАНЕЕ ИЗВЕЩЕНЫ О ВОЗМОЖНОСТИ ТАКОГО УЩЕРБА.
...
14. ОГРАНИЧЕНИЕ ОТВЕТСТВЕННОСТИ И РАЗМЕРА ВОЗМЕЩЕНИЯ УЩЕРБА.
Независимо от характера и причин причиненного вам ущерба или понесенных убытков (включая все без исключения перечисленные выше случаи ущерба и/или убытков, а также любые прямые или общие ущерб и/или убытки), максимальный размер ответственности корпорации Майкрософт или любого ее поставщика по любому из положений настоящего лицензионного соглашения, и размер причитающейся Вам компенсации(за исключением компенсации в виде ремонта или замены продукта, предоставляемой по выбору корпорацией Майкрософт в связи с нарушением ограниченной гарантии) не может превысить большей из следующих сумм: суммы, фактически уплаченной вами при приобретении продукта, или суммы в размере пяти долларов США. Перечисленные выше ограничения, исключения и отказы (включая разделы 11 и 12, а также ограниченную гарантию) действуют в наибольшей степени, допускаемой применимым законодательством, даже если полученная компенсация не покрывает понесенный ущерб.
...
-
...
Вот где интересная работа. Можно даже сказать, наука. Сам на такую побежал бы, если бы позвали.
...
Скажите, а как вы относитесь к таким проектам как FreeDOS? ... лицензионно чисто ... полностью открыто ...
Кстати, насколько мне известно, тот же ИПУ РАН поставляет в Иран в составе ПТК СВБУ Бушер несколько машин работающих под управлением IBM PCDOS ... в Индию тоже ...
Пример про людей, переписавших ДОС, я привёл только для того, чтобы обозначить направление - разработка своей ОС. Даже не ОС, а некой среды запуска. Но никак не клон ДОС. ДОС - убожище. Для разработки её используют только ретрограды, которые больше ничего, кроме Борланд Паскаль, не могут. Эти ретрограды обычно являются одиозными личностями. Тени буйного прошлого. 286-я самосборная машина за 1000 долларов. Установка перацкой ДОС на неё за 500. Это есть причина поставки ДОС. ДОС не решает банальнейших задач. Нужно : поддержка дисковых массивов 2 терабайта и более, оперативной памяти 2 гигабайта и более, многопроцессорных/многоядерных конфигураций, нескольких видеокарт с каким-никаким ускорением. Также, нужна какая-то виджетная библиотека, работающая с графикой, какой-то сетевой протокол типа TCP и UDP, какая-то файловая система, не имеющая проблем с размерами файлов и томов, драйверы для стандартного PC железа, какая-то многозадачность, какой-то пакетный менеджер, какие-то шрифты. Вот и всё практически. Не так сложно, как может показаться. Мы с коллегами обсуждаем этот вопрос постоянно и давно пришли к выводу, что данный путь - единственно правильнй. Набрать не 3 человека, а 20. Совшенно реально создать некую исполняемую среду. Компияотор и среда разработки - GNU toolchain. Очень конфигурабельна. Я код gcc заталкивал в самосборную машину без ОС вообще.
-
а по теме... свободное ПО, помоему глупо ставить на такие ответственные проекты... т.к. в такого рода ПО четко прописано "ВЫ ИСПОЛЬЗУЕТЕ ЭТОТ ПРОГРАМНЫЙ ПРОДУкТ НА СВОЙ СТРАХ И РИСК", если что - ни на кого потом не свалишь ответственность...
Почитайте внимательно лицензионное соглашение на Microsoft Windows ... хотя бы раз в жизни сделайте это - узнаете много нового.
Или вы наивно полагаете что продав вам закрытое коммерчесоке ПО какая то компания захочет нести ответственность за последствия его применения? или станет вам что то гарантировать???
Зачем так возмущаться. В современном мире ни один поставщик системного ПО не берёт на себя никакой ответственности. Прочитайте предыщую фразу ещё раз. Ни один. Это объясняется очень просто. Из судов не вылезешь, даже если не виноват ни в чём. Милларды инсталляций, каждый захочет выгородить себя в случае чего, свалив вину на Била. Судьи некомпетентны. Любая софтверная фирма обанкротится на следущий же день после того, как даст хоть какие-то гарантии.
-
ПРО индийских программистов ничего не могу сказать, общался только с идийскими аналитиками. У меня сложилось такое впечатление: наглые, тупые, ленивые обезьяны. Подтверждение тому: ни одного физически оконченного проекта по внедрению АБС в наших банках. Все эти i-flex, infosys - говно.
-
ПРО индийских программистов ничего не могу сказать, общался только с идийскими аналитиками. У меня сложилось такое впечатление: наглые, тупые, ленивые обезьяны. Подтверждение тому: ни одного физически оконченного проекта по внедрению АБС в наших банках. Все эти i-flex, infosys - говно.
А чего ты хотел? ты для них из низшей касты
-
Даже если абстрагироваться от светлых идей технологической независимости. Я уже не использую линуксовую файловую системы в своей работе. Ни одна из них не даёт нужных мне возможностей. Написал свою файловую систему. Протокол ntp и прекрасную систему синхронизации времени ntpd. Отказались три года назад. Написал свой протокол. Хоть дотюниваю алгоритм прямо сейчас, но это оказалось а разы проще и эффективнее, чем ковырять это барахлище ntp. Вот такая практика.
-
ПРО индийских программистов ничего не могу сказать, общался только с идийскими аналитиками. У меня сложилось такое впечатление: наглые, тупые, ленивые обезьяны. Подтверждение тому: ни одного физически оконченного проекта по внедрению АБС в наших банках. Все эти i-flex, infosys - говно.
А чего ты хотел? ты для них из низшей касты
\\\"Саша С. такой затейник\\\" (с) одна девачка с этого форума.
-
ПРО индийских программистов ничего не могу сказать, общался только с идийскими аналитиками. У меня сложилось такое впечатление: наглые, тупые, ленивые обезьяны. Подтверждение тому: ни одного физически оконченного проекта по внедрению АБС в наших банках. Все эти i-flex, infosys - говно.
А чего ты хотел? ты для них из низшей касты
\\\"Саша С. такой затейник\\\" (с) одна девачка с этого форума.
меньше пользуйся КПК - глаза сломаешь :)
-
Вы можете иронизировать про обезьян сколько угодно. Но когда эти "обезьяны" увидят убожище на Мотифе, они начнут ржать. Они не папуасы и технологически очень продвинуты. Гораздо более продивинуты, чем очень многие наши "спецы". На АЭС наберут хороших специалистов, будьте уверены. Засмеют. Унылая отмазка "а больше и не надо" вызовет смех в лицо.
-
Вы можете иронизировать про обезьян сколько угодно. Но когда эти "обезьяны" увидят убожище на Мотифе, они начнут ржать.
Видели ... пока не ржут ... похоже они понятия не имеют что такое мотиф.
Они не папуасы и технологически очень продвинуты. Гораздо более продивинуты, чем очень многие наши "спецы". На АЭС наберут хороших специалистов, будьте уверены.
Что верно то верно ... на приеме-сдаточных испытаниях ПТК СВБУ Куданкулам на НИИИС они очень правильные вопросы задавали, видно что люди приехали не для галочки, а действительно понять хотят что, как и почему ... еще раз повторюсь - вопросы задают очень правильные ...
Засмеют. Унылая отмазка "а больше и не надо" вызовет смех в лицо.
Дело не в том что "больше не надо" ... а в том что в понимании некоторых "проще = надежней".
Хотя это будет работать лишь до тех пор пока простота не опустится до уровня примитивизма и убожества ... когда для выполнения элементарной операции включения насоса или закрытия запорной арматуры требуется каждый раз делать не меньше 5-6 кликов мышкой.
-
как у нас препод по управлению в сложных системах говорил, простота - косвенный критерий надежности)