На наш взгляд претензии к качеству и скорости у всех как раз одинаковые, речь не об этом, а о том, за счет чего они достигаются: техника или техника + люди
Когда мы слышим про 100% точность всегда вспоминаем одну небезызвестную компанию, которая принимала штрафы с довольно солидной комиссией в ГИБДД. Всех удивляло то, что можно было от руки заполнить квитанцию и платеж принимался. Руководство компании в шутку говорило, что там продвинутые космические технологии и все такое. Самое интересное, что многие в это верили) Хотя понятно было, что там был "миллион китайцев". 100% точность дает только сервис дополненный верификацией.
Для обработки 1 документа 2,5 мин на наш взгляд это запредельно долго, даже если в документе не 1, а 3 страницы. Т.е. например, для небухгалтерских документов - судебные, договоры, кредитное досье 2,5 мин это было бы не плохо, а для бухгалтерской первички - это явно перебор.
спасибо за такое развернутое мнение. и за добавление про категории (пусть будет бонус-треком для дочитавших до самого конца) :))
прокомментируем хотя бы частично, по некоторым замечаниям.
История всё-таки из реальной жизни, и, как даже здесь, в комментариях, было отмечено, историй таких миллион. Тот очень редкий случай когда можно.
Зачем писали:
— Вы абсолютно правы — алерты и т.п. — по большей части лишь антураж, главная тема — люди, их компетенции и их желание организовать работу;
— табличка. некоторые наши заказчики уже брали её как заготовку и делали свой образец, до которого всё руки не доходили, глядишь и тут кому-то пригодится (ITIL, тем более работающий, есть далеко не у всех);
— надеемся (может, наивно), что заказчики прочитают, сделают правильные выводы, что и им пользу принесет и интеграторам с которыми работают, win-win, а не сидеть как в окопе до последнего, как это слишком часто бывает.
Настройки не подтянулись автоматически — конструктивная особенность модели, т.к. в инструкции к смене контроллера нужно «ручное» участие администратора (даже одну-две кнопки нажать в GUIвсе равно участие, как впрочем и одна команда в CLI).
«Ничего не пишет» — СХД как раз писала. Но слова профи: он вынул, он вставил, загорелась зеленая лампочка… Т.е. «профи» решил что все ОК, когда погас индикатор ошибки и загорелась зеленая лампочка… Обращать внимание на Алерты «не его дело», а смотреть логи вообще «нонсенс». Последнее предложение — сарказм. А что делал админ? Новый админ видимо пришел после этого, а старый уже ушел. Т.к. во время ЧП профи говорил про себя, что он вынул, вставил и лампочка загорелась.
Подробнее про СХД, чтобы не купить — история пятилетней давности, эта модель больше трёх лет снята с производства, т.е. её уже не купишь. хотя теплоты к этому вендору у нас никакой, так жестоко поливать совсем неэтично, опять таки 5 лет прошло.
Почему не проверили работоспособность контроллера, не знаю. Нас не допускали на площадку, " Мы и сами справимся". Настоять же — нет оснований.
Про нас могу сказать, что мы доходчиво донесли информацию о проблемах и возможных последствиях, как только получили логи с СХД для помощи в открытии тикета.
То, что контроллер умер у профи, он видимо осознал только когда были сняты логи, иначе нам просто не понять такое отношение. Полученные же Алерты его администратор заводил в местный аналог «service desk», где профи кстати и отвечал. Со слов администратора из второго дня могу сказать, что профи должен был их видеть, как минимум до тех пор, пока админу не сказали: работает, не трогай. Далее не знаю, сам профи не делился подобной информацией. А как профи читал алерты, если читал, тем более не знаю, но результаты довольно красноречивые: сообщения СХД игнорировались.
Основной движущей силой обновления версий пакетов, поставляемых в составе OSL, являются заявки клиентов. То есть, если поступает сигнал, что кому-то нужна более новая версия, или дополнительные опции сборки, — такую заявку стараются выполнить по мере возможностей.
Время от времени производится массовое обновление, при котором всё, что можно легко обновить, обновляется до самой последней версии. (Ну, или не сразу всё, а какой-нибудь большой пласт пакетов; в следующий раз — другой пласт, и т. д.)
Сложные проекты, такие как пресловутый Firefox или там Java, обновляются в особом порядке: даже если удаётся по-быстрому собрать полностью работоспособную версию, она может оказаться непригодной для поставки конечным пользователям ввиду низкой производительности, — чтобы допилить очередную реинкарнацию движка Java или JavaScript, нужно привлекать целые команды разработчиков.
Постоянно гоняться за bleeding-edge версиями при каждой сборке системы (а она происходит раз в одну-две недели), МЦСТ не может, так как считает необходимым воочию убедиться в работоспособности каждой софтины, а не просто довольствоваться фактом успешного завершения компиляции, — проверка трудозатратна, а людских ресурсов и так вечно не хватает.
Поэтому обращение в техподдержку со своей проблемой — единственно возможный способ привлечь специалистов производителя к её решению. А если вы ещё и поделитесь своим опытом, наблюдениями и неудачами, то, возможно, сэкономите своё и их время.
Вообще, отдел общего программного обеспечения заявляет — хотя бы на словах — свою приверженность идеям open source: каждый желающий может внести на рассмотрение свои исправления и дополнения. Возможно, со временем сформируется критическая масса пользователей, желающих всегда иметь наиболее свежие версии софта, и они (как специалисты каждый в своей предметной области, коими программисты МЦСТ, естественно, не являются) напишут юнит-тесты для автоматической проверки работоспособности всех основных функций того или иного пакета. Тогда можно будет реализовать continuous integration и следить за апстримами на постоянной основе.
Без дополнительных подробностей, можно разве что посочувствовать и отметить, что лично мне вот, например, не удалось собрать Firefox даже под x86 Linux — но из этого следует только то, что я для такого недостаточно компетентен, а не то что указанный проект несовместим с той платформой. Может, напишете более развёрнутый комментарий к третьей части статьи, где обсуждались средства разработки OSL вообще и наличие уже собранного Erlang в частности? Кроме того, можно же обратиться в техподдержку МЦСТ, если серьёзно нужна именно новая версия, — мне пока тоже не понятно, почему мейнтейнеры дистрибутива держатся за старые и очень старые версии некоторых пакетов, даже когда новые прекрасно собираются и не несут проблем обратной совместимости.
В АО «МЦСТ» завершён цикл подготовки серийного производства персональных компьютеров Эльбрус-401 РС. За прошедшее время компания наладила кооперацию отечественных предприятий — контрактных производителей, отладила схемотехнические решения. Основные технологические операции по производству компьютеров, в том числе поверхностный монтаж печатных плат, производятся в России.
В связи со снижением производственных издержек, оптимизированы стоимостные параметры вычислительных комплексов: цена Эльбрус-401 РС модификации «Б», имеющей тактовую частоту процессора 750 МГц, в розничной продаже составляет 199 тысяч рублей (включая НДС).
«Проблема у х86 в том, что его внеочередное исполнение существует только в рамках окна определённой длинны. Если длина тела цикла шире этого окна — ооо идёт в мусорку».
Эльбрус имеет гораздо более широкое окно, что в сочетании с большим количеством регистров позволяет замахиваться выше, чем x86, — как, например, в случае с шифром ГОСТ, тело которого удаётся полностью развернуть, из-за чего Э4С@800 оказывается вдвое быстрее i7-2600@3400.
«А если мне нужен синус и косинус сразу?»
Вы не поверите, но таки eml_Vector_SinCos_32F и eml_Vector_SinCos_64F. Вообще, там 60 страниц одного только перечисления названий функций. К тому же, они открыты для предложений: если функция объективно полезная, можно добавить новую.
«Никакой человек не пишет на ассемблере, считая тайминги на листочке».
Даже на x86 без учёта времени выполнения инструкций — почти никак (ну, как минимум надо себе представлять, какие инструкции предпочтительнее, и какие зависимости они создают), то на архитектурах с явным параллелизмом всё на этом же и держится. Как вы будете раскидывать [пусть даже независимые друг от друга] инструкции между широкими командами, если не знаете, насколько каждая из них будет задерживать выполнение всей команды?
«Подавляющие большинство операций в реальном мире не параллелятся, либо параллелятся слабо. Собственно поэтому для задействования этого параллелизма надо параллельно исполнять множество потоков».
Если какая-то задача в принципе не распараллеливается, то при чём тут любой конкретно взятый процессор и компилятор? А если всё-таки распараллеливается для одной архитектуры, значит, можно как-нибудь распараллелить и для другой. Компилятор C/C++ помешает? Ну, если вы уже написали что-то для SSE, значит, вы пишете не совсем на C/C++, а на конкретном диалекте с использованием конкретных спецфункций, — этого добра и в МЦСТ-шном LCC хватает, как своего, так и GCC-совместимого.
«Надо считать не один отдельный синус, а много. На практике эта задача сложнее векторизации, а даже векторизацию до сих пор ни один компилятор делать, кроме примитивных случаев, не умеет».
Есть такая буква в библиотеке EML! Вычисление синуса элементов вектора — eml_Vector_Sin_32F, eml_Vector_Sin_64F. И, если верить утверждениям МЦСТ (я не проверял), компилятор в некоторых случаях может заменять обычный вызов скалярной функции sin() на вызов такой вот оптимизированной функции из библиотеки.
«Даже банально раскидать инструкции одного потока по каналам исполнения — такая же непосильная для компилятора задача».
Внезапно, именно этим LCC и занимается; собственно, на его оптимизациях всё и держится. Насколько он эффективен в среднестатистическом случае, судить не берусь, но сами МЦСТшники считают, что человеку не под силу с ним тягаться: если только вы не пишете ну очень критичный кусочек кода с большим потенциалом ручной оптимизации (для этого вы должны знать систему команд и учитывать тайминги каждой инструкции в составе широкой команды), не стоит даже пытаться смотреть в сторону ассемблера.
«У х86 есть SSE, AVX, а у Эльбруса вроде DSP и какие-то свои фичи; притом вряд ли их кто-то использует кроме самого МЦСТ в своих либах».
Позиция МЦСТ такова, что на платформе «Эльбрус» надо пользоваться высокоуровневыми языками C/C++ и Fortran и специальными библиотеками для них, а опускаться на уровень машинных команд можно разве что в исключительных случаях. Как бы то ни было, у их компилятора C/C++ есть флаги, включающие поддержку GCC-шных встроенных функций для работы с MMX, 3DNow, SSE вплоть до 4.2, XOP, AVX, FMA4, CLMUL, BMI, F16C, AES, — насколько я понимаю, некоторое из этого и так реализовано в железе (просто инструкции другие), а остальное эффективным образом конвертируется в нативные широкие команды.
EML таки задействует встроенный в процессор DSP, или она работает на основных ядрах? Судя по документации, EML таки не задействует DSP; и вообще, компиляция для DSP — это особое дело. В любом случае, процессор «Эльбрус-4С», на основе которого построен используемый авторами сервер «Эльбрус-4.4», не имеет DSP-ядер.
Критичность одних проблем здесь сильно преувеличивается, тогда как другие остаются без внимания.
Автоматическая идентификационная система — это всего лишь средство добровольной самоидентификации, способ оповестить окружающих о своём присутствии и намерениях. Конечно, подтверждение подлинности этой системе не помешало бы (если не считать мороки с поддержанием цепи доверия). Но от того, что кто-то будет заглушать или подделывать информацию об объектах, реальное положение и размер этих объектов не изменится, — а такие вещи принято контролировать по радару. Да, радару тоже можно противодействовать, — ставить помехи, имитировать ложные цели, — но это сложнее технически, и трудно повлиять на картину за пределами своего сектора.
Потом, что значит «подделывать»? Идентификатор судна и его характеристики вводит в свой АИС-передатчик сам пользователь. Что значит «глушить»? Мощность передатчиков и чувствительность приёмников, равно как и характеристики антенн, у всех разные, — никто не гарантирует, что сигнал будет проходить хоть в сколь-нибудь малой зоне безопасного расхождения. Поэтому АИС — служба ненадёжная, тем более что у малых судов (яхт) передатчика может попросту не быть, а некоторые суда его [временно] отключают, как и сказано в статье; военные корабли вообще могут принципиально не включать никогда, и дипломатических конфликтов это не вызывает.
Создание кораблей-призраков? Так ведь в самой системе заложено понятие виртуальных объектов — чисто умозрительных меток. Более того, заложено понятие нахождения объекта вне указанной позиции. В общем, АИС — это именно способ привлечения внимания, а не самодостаточное средство освещения надводной обстановки.
Подделка погодной информации? Каналов доставки этой информации есть несколько, в том числе радиофакс (без проверки подлинности) и Интернет (где пренебрегать защитой тоже можно, но не обязательно).
По поводу компьютерных систем, в частности навигационных станций, — тут надо чётко различать границы ответственности. Одно дело, если судовладелец покупает у разработчика ЭКНИС только софт и самостоятельно ставит на свой компьютер, — тут он сам себе буратино. Другое дело, когда мостиковая система поставляется как готовый комплекс в опечатанном корпусе и общающийся с пользователем в режиме «киоска», то есть без возможности доступа к другим программам и свободного перемещения по файловой системе, — тут ещё могут вмешиваться вопросы сертификации.
Доступность Интернета на судне ещё не означает доступность судовых систем из Интернета. Конечно, бывает и так, что кто-нибудь торчит глобальным IP-адресом во внешний мир и не использует межсетевые экраны (о чём свидетельствует комментарий shanker), но здесь нет ничего специфичного для морской отрасли — проблема-то общечеловеческая.
Корректная работа ЭКНИС очень важна, разумеется, но нарушение её работы не должно приводить к катастрофам. Во-первых, в качестве резервного средства много где ещё остаются бумажные карты. Во-вторых, любое сколь-нибудь серьёзное судно (а только такие суда имеют право на безбумажный «воркфлоу», потому что только у них есть деньги на настоящую сертифицированную ЭКНИС) обязательно оснащено радаром и эхолотом, а то и несколькими их видами сразу, — одновременная поломка всего этого маловероятна.
Возможность подделки или уничтожения данных «чёрного ящика» — это нехорошо, да. Но надо отдавать себе отчёт, что если у злоумышленника (которым может быть сам судовладелец или судоводитель) есть физический доступ к объекту интереса — этот объект заведомо подвержен компрометации. Решение очевидно: хранить данные у независимой стороны, — например, отправляя сводку по спутниковому каналу 1-2 раза в минуту (или реже, если этого будет достаточно).
Глушение и подделка сигналов GPS/DGPS, как и AIS, — ну а какой радиосигнал нельзя заглушить? Что до аутентификации навигационных спутников для широкой публики, то над этим вроде ещё только работают, — как можно ожидать решения этой проблемы со стороны производителей трекеров? (Незащищённая передача по наземным каналам — другой вопрос.)
Что осталось за кадром. Если уж упомянули ЭКНИС, то неплохо бы провести анализ того, насколько эти системы защищены от подделки, разрушения и хищения информации в принципе (то есть без учёта непреднамеренных уязвимостей). Например, насколько реально подсунуть в ту или иную систему какие-нибудь поддельные карты вместо настоящих или в дополнение к ним, или повысить статус «неофициальных» карт до «официальных» (официальные карты выпускаются только головными гидрографическими агентствами государств, все остальные карты на их основе — неофициальные; серьёзные суда обязаны использовать только официальные карты). Насколько легко обойти защиту от копирования — перенести приобретённые карты на другое судно с такой же ЭКНИС, или импортировать карты, лицензия на которые не покупалась или истекла (для больших судов такое «пиратство» может не иметь смысла, если инспекторы контролируют их картографическое обеспечение по фактическим отчётам от продавцов). Ситуация тут примерно такая же, как с АИС, — фундамент систем управления правами закладывался в дремучие годы, когда понятия о криптографической стойкости были другие, и специалистов в этой сфере было мало.
Также осталось за кадром, что в дополнение к AIS сейчас существует LRIT (long-range identification and tracking) с двусторонним обменом информацией через спутниковые каналы. Интересно было бы знать, как там дела обстоят с защищённостью.
Вообще, военные моряки примерно треть рабочего времени должны уделять учениям по борьбе за живучесть корабля — сюда входит не только заделывание пробоин и тушение пожаров, но и эвакуация, в том числе помощь другим членам экипажа.
В вашем комментарии читается некое противоречие: «У вас не хватило денег на большую и соответственно более дешевую партию? — Попробуйте выпустить ещё over 9000 других нишевых устройств, наготовьте кучу документации и SDK, раздайте всё это бесплатно куче людей и сидите ждите — авось какой-нибудь проект да выстрелит!» Чем-то напоминает совет в стиле «Если нет хлеба, пусть едят пироги». То есть мысль понятна, но не ясно одно: где денег-то изначально взять на эти недешёвые эксперименты?
Не сомневаюсь, что чтиво захватывающее, но это всё же 1960-е годы, а интересно проследить, как двигался технических прогресс всё это время, и как бок о бок с ним продолжала идти человеческая безалаберность и глупость, находя всё новые и новые способы обойти защиту от дурака.
Раз уж заговорили о намеренном затоплении отсеков для спрямления, надо бы рассказать о том, как именно капитан принимает решение, какие конкретно отсеки затапливать. Подозреваю, что в этом плане ничегошеньки не изменилось с 20-го века, и вместо моделирования реальной ситуации используются заранее заготовленные таблицы, в которых расписаны только самые типовые случаи.
Также неплохо бы описать современные средства успокоения качки, которые не только вносят немалый вклад в повседневный комфорт пассажиров, но также защищают судно от переворачивания на ходу и при бедствии.
Ещё есть интересные вопросы картографического и метеорологического обеспечения. На многих судах до сих пор пользуются бумажными и растровыми картами, а сводку погоды принимают по радиофаксу в таком же допотопном виде, да ещё с шумами. Хотя требования к крупным судам, по идее, строже.
Наконец, про радиоэлектронные средства аварийной сигнализации тоже можно было бы что-нибудь сказать.
И самый поучительный момент — на реальных примерах показать, как все эти меры безопасности могут разбиваться о человеческий фактор.
Поддержка интерпретируемых языков (тех, для кого это единственный или один из возможных режимов) возможна «из коробки» — если оно, конечно, соберётся, но это на любой платформе так. При этом технология защищённого исполнения программ будет применяться к интерпретатору данного языка, поскольку ваша интерпретируемая программа обращается к памяти не сама по себе, а через интерпретатор.
Поддержка компилируемых [в нативный код] языков возможна, только если компилятор умеет транслировать исходную программу в код на C/C++ или Fortran. Ведь, чтобы генерировать машинный код, по сути необходимо выполнить портирование компилятора на новую архитектуру — а это процесс сложный в общем случае. Более того, если схема кодирования машинных команд будет оставаться закрытой, то получить машинный код можно будет только через компилятор ассембера.
Поддержка интерпретируемых языков, использующих компиляцию в машинный код для ускорения работы, возможна либо за счёт отключения этой самой компиляции, либо путём портирования, — на примере с Java и JavaScript мы увидели, что первый релиз был сделан по пути наименьшего сопротивления, но теперь МЦСТ работает над повышением производительности.
Насчёт автоматической сборки мусора — тут мне сложно даже предположения строить; постараюсь провентилировать этот вопрос, если/когда дело дойдёт до написания отдельной статьи о технологии защищённого исполнения (по идее, у меня она первая на очереди).
Вещи, о которых вы говорите во всех своих комментариях, — сущности сиюминутные: «рыночная доля», «экосистема», «зоопарк», «перестанут писать», «направление умрёт», «сложившийся рынок труда», «специалисты по %s». Индикаторами тут являются ваши же слова «полгода», «конец внедрения» и даже «10 лет» — это всё момент в истории, хоть и составляет существенную долю человеческой жизни и ещё более существенную долю типичной трудовой карьеры.
Школьное образование закладывает основы. Нас в своё время на уроках по предмету «Основы информатики и вычислительной техники» учили именно основам — что такое циклы и ветвления, функции и переменные, булева алгебра, как нарисовать блок-схему алгоритма. Эти знания не потеряют своей актуальности никогда, даже если компьютеры станут квантовыми, не говоря уже о том, какая операционная система или какой язык программирования будет в тренде в тот или иной момент времени.
Нас в школе не учили пользоваться конкретными программными продуктами. Разумеется, программы писались на реальных языках, и поэтому синтаксис, конечно, изучался — но смысл был не в том, чтобы овладеть каким-то конкретным языком, а в том, чтобы опробовать все те же общие концепции. А вот в институте, напротив, мне не очень повезло, и курсы функционального и логического программирования, например, свелись к тупому изучению Лиспа и Пролога — настолько приземлённому, что даже я так и не понял, в чём фишка этих парадигм и чем они отличаются от традиционного императивного стиля. Про курсы Паскаля, Си и C++, которые в расписании тоже как-то красиво назывались, я уж вообще молчу. Это было именно «ремесленное» изучение, место которому скорее в ПТУ, — как раз то, о чём вы говорите: сегодня вчера этот Паскаль или FoxPro на коне, а завтра о них уже никто не помнит, и с трудом зазубренные студентом накануне экзамена названия функций нужны чуть менее, чем вообще нигде.
Но возвращаясь к операционным системам. Пользованию DOS или NC нас тогда тоже никто не учил, просто показали более-менее, куда тыкать — и этого было достаточно, потому что учить там действительно особо нечему. А вот то, что Linux обошли вниманием не только в школе, но и в институте, — это серьёзное упущение. Ведь смысл изучения *nix (именно Unix-семейства в целом) на академическом уровне — не в том, какой дистрибутив выбрать, какую команду применить для запуска текстового редактора и какой последовательностью клавиш выйти из этого редактора, а в понимании фундаментальных концепций, на которых всё строится. Простор для изучения там необъятный: при желании, можно для любой технической (околокомпьютерной) специальности найти свои темы, в которые следует углубиться дополнительно.
Насколько я понимаю, сейчас в школах учат запускать Windows и набирать тексты в Word. При таком подходе, даже если заменить эти продукты на Linux и OpenOffice соответственно, толку не прибавится ни капельки. Учить в школе и институте надо не тому, что актуально, а тому, что никогда потеряет своей актуальности в принципе.
У корабля на борту есть стационарное вооружение, а у судна — нет.
Кстати, термин «вооружение» имеет гораздо более широкий смысл, чем «оружие»: сюда может входить не только система управления орудийными установками или система управления кораблём в целом, но и вообще любая аппаратура и технические средства, позволяющие решать основную задачу. То есть это почти синоним слова «оборудование»; но, очевидно, такие вещи как, например, оборудование санузла (простите, гальюна) в эту категорию не входит — разве что команда объелась гороха.
А вот может ли на судне обеспечения какое-то оборудование считаться «вооружением» — это хороший вопрос. Даже если там установлена аппаратура государственного опознавания, радиолокационная станция, засекречивающая аппаратура связи — это всё ещё «вооружение» или уже нет?
На наш взгляд претензии к качеству и скорости у всех как раз одинаковые, речь не об этом, а о том, за счет чего они достигаются: техника или техника + люди
Когда мы слышим про 100% точность всегда вспоминаем одну небезызвестную компанию, которая принимала штрафы с довольно солидной комиссией в ГИБДД.
Всех удивляло то, что можно было от руки заполнить квитанцию и платеж принимался.
Руководство компании в шутку говорило, что там продвинутые космические технологии и все такое. Самое интересное, что многие в это верили)
Хотя понятно было, что там был "миллион китайцев".
100% точность дает только сервис дополненный верификацией.
Для обработки 1 документа 2,5 мин на наш взгляд это запредельно долго, даже если в документе не 1, а 3 страницы.
Т.е. например, для небухгалтерских документов - судебные, договоры, кредитное досье 2,5 мин это было бы не плохо, а для бухгалтерской первички - это явно перебор.
прокомментируем хотя бы частично, по некоторым замечаниям.
История всё-таки из реальной жизни, и, как даже здесь, в комментариях, было отмечено, историй таких миллион. Тот очень редкий случай когда можно.
Зачем писали:
— Вы абсолютно правы — алерты и т.п. — по большей части лишь антураж, главная тема — люди, их компетенции и их желание организовать работу;
— табличка. некоторые наши заказчики уже брали её как заготовку и делали свой образец, до которого всё руки не доходили, глядишь и тут кому-то пригодится (ITIL, тем более работающий, есть далеко не у всех);
— надеемся (может, наивно), что заказчики прочитают, сделают правильные выводы, что и им пользу принесет и интеграторам с которыми работают, win-win, а не сидеть как в окопе до последнего, как это слишком часто бывает.
«Ничего не пишет» — СХД как раз писала. Но слова профи: он вынул, он вставил, загорелась зеленая лампочка… Т.е. «профи» решил что все ОК, когда погас индикатор ошибки и загорелась зеленая лампочка… Обращать внимание на Алерты «не его дело», а смотреть логи вообще «нонсенс». Последнее предложение — сарказм. А что делал админ? Новый админ видимо пришел после этого, а старый уже ушел. Т.к. во время ЧП профи говорил про себя, что он вынул, вставил и лампочка загорелась.
Подробнее про СХД, чтобы не купить — история пятилетней давности, эта модель больше трёх лет снята с производства, т.е. её уже не купишь. хотя теплоты к этому вендору у нас никакой, так жестоко поливать совсем неэтично, опять таки 5 лет прошло.
Почему не проверили работоспособность контроллера, не знаю. Нас не допускали на площадку, " Мы и сами справимся". Настоять же — нет оснований.
Про нас могу сказать, что мы доходчиво донесли информацию о проблемах и возможных последствиях, как только получили логи с СХД для помощи в открытии тикета.
То, что контроллер умер у профи, он видимо осознал только когда были сняты логи, иначе нам просто не понять такое отношение. Полученные же Алерты его администратор заводил в местный аналог «service desk», где профи кстати и отвечал. Со слов администратора из второго дня могу сказать, что профи должен был их видеть, как минимум до тех пор, пока админу не сказали: работает, не трогай. Далее не знаю, сам профи не делился подобной информацией. А как профи читал алерты, если читал, тем более не знаю, но результаты довольно красноречивые: сообщения СХД игнорировались.
Мне объяснили так:
Постоянно гоняться за bleeding-edge версиями при каждой сборке системы (а она происходит раз в одну-две недели), МЦСТ не может, так как считает необходимым воочию убедиться в работоспособности каждой софтины, а не просто довольствоваться фактом успешного завершения компиляции, — проверка трудозатратна, а людских ресурсов и так вечно не хватает.
Поэтому обращение в техподдержку со своей проблемой — единственно возможный способ привлечь специалистов производителя к её решению. А если вы ещё и поделитесь своим опытом, наблюдениями и неудачами, то, возможно, сэкономите своё и их время.
Вообще, отдел общего программного обеспечения заявляет — хотя бы на словах — свою приверженность идеям open source: каждый желающий может внести на рассмотрение свои исправления и дополнения. Возможно, со временем сформируется критическая масса пользователей, желающих всегда иметь наиболее свежие версии софта, и они (как специалисты каждый в своей предметной области, коими программисты МЦСТ, естественно, не являются) напишут юнит-тесты для автоматической проверки работоспособности всех основных функций того или иного пакета. Тогда можно будет реализовать continuous integration и следить за апстримами на постоянной основе.
Налетай, подешевело!
По сегодняшнему курсу, это 3333 доллара.
Эльбрус имеет гораздо более широкое окно, что в сочетании с большим количеством регистров позволяет замахиваться выше, чем x86, — как, например, в случае с шифром ГОСТ, тело которого удаётся полностью развернуть, из-за чего Э4С@800 оказывается вдвое быстрее i7-2600@3400.
«А если мне нужен синус и косинус сразу?»
Вы не поверите, но таки eml_Vector_SinCos_32F и eml_Vector_SinCos_64F. Вообще, там 60 страниц одного только перечисления названий функций. К тому же, они открыты для предложений: если функция объективно полезная, можно добавить новую.
«Никакой человек не пишет на ассемблере, считая тайминги на листочке».
Даже на x86 без учёта времени выполнения инструкций — почти никак (ну, как минимум надо себе представлять, какие инструкции предпочтительнее, и какие зависимости они создают), то на архитектурах с явным параллелизмом всё на этом же и держится. Как вы будете раскидывать [пусть даже независимые друг от друга] инструкции между широкими командами, если не знаете, насколько каждая из них будет задерживать выполнение всей команды?
Если какая-то задача в принципе не распараллеливается, то при чём тут любой конкретно взятый процессор и компилятор? А если всё-таки распараллеливается для одной архитектуры, значит, можно как-нибудь распараллелить и для другой. Компилятор C/C++ помешает? Ну, если вы уже написали что-то для SSE, значит, вы пишете не совсем на C/C++, а на конкретном диалекте с использованием конкретных спецфункций, — этого добра и в МЦСТ-шном LCC хватает, как своего, так и GCC-совместимого.
«Надо считать не один отдельный синус, а много. На практике эта задача сложнее векторизации, а даже векторизацию до сих пор ни один компилятор делать, кроме примитивных случаев, не умеет».
Есть такая буква в библиотеке EML! Вычисление синуса элементов вектора — eml_Vector_Sin_32F, eml_Vector_Sin_64F. И, если верить утверждениям МЦСТ (я не проверял), компилятор в некоторых случаях может заменять обычный вызов скалярной функции sin() на вызов такой вот оптимизированной функции из библиотеки.
«Даже банально раскидать инструкции одного потока по каналам исполнения — такая же непосильная для компилятора задача».
Внезапно, именно этим LCC и занимается; собственно, на его оптимизациях всё и держится. Насколько он эффективен в среднестатистическом случае, судить не берусь, но сами МЦСТшники считают, что человеку не под силу с ним тягаться: если только вы не пишете ну очень критичный кусочек кода с большим потенциалом ручной оптимизации (для этого вы должны знать систему команд и учитывать тайминги каждой инструкции в составе широкой команды), не стоит даже пытаться смотреть в сторону ассемблера.
Позиция МЦСТ такова, что на платформе «Эльбрус» надо пользоваться высокоуровневыми языками C/C++ и Fortran и специальными библиотеками для них, а опускаться на уровень машинных команд можно разве что в исключительных случаях. Как бы то ни было, у их компилятора C/C++ есть флаги, включающие поддержку GCC-шных встроенных функций для работы с MMX, 3DNow, SSE вплоть до 4.2, XOP, AVX, FMA4, CLMUL, BMI, F16C, AES, — насколько я понимаю, некоторое из этого и так реализовано в железе (просто инструкции другие), а остальное эффективным образом конвертируется в нативные широкие команды.
Автоматическая идентификационная система — это всего лишь средство добровольной самоидентификации, способ оповестить окружающих о своём присутствии и намерениях. Конечно, подтверждение подлинности этой системе не помешало бы (если не считать мороки с поддержанием цепи доверия). Но от того, что кто-то будет заглушать или подделывать информацию об объектах, реальное положение и размер этих объектов не изменится, — а такие вещи принято контролировать по радару. Да, радару тоже можно противодействовать, — ставить помехи, имитировать ложные цели, — но это сложнее технически, и трудно повлиять на картину за пределами своего сектора.
Потом, что значит «подделывать»? Идентификатор судна и его характеристики вводит в свой АИС-передатчик сам пользователь. Что значит «глушить»? Мощность передатчиков и чувствительность приёмников, равно как и характеристики антенн, у всех разные, — никто не гарантирует, что сигнал будет проходить хоть в сколь-нибудь малой зоне безопасного расхождения. Поэтому АИС — служба ненадёжная, тем более что у малых судов (яхт) передатчика может попросту не быть, а некоторые суда его [временно] отключают, как и сказано в статье; военные корабли вообще могут принципиально не включать никогда, и дипломатических конфликтов это не вызывает.
Создание кораблей-призраков? Так ведь в самой системе заложено понятие виртуальных объектов — чисто умозрительных меток. Более того, заложено понятие нахождения объекта вне указанной позиции. В общем, АИС — это именно способ привлечения внимания, а не самодостаточное средство освещения надводной обстановки.
Подделка погодной информации? Каналов доставки этой информации есть несколько, в том числе радиофакс (без проверки подлинности) и Интернет (где пренебрегать защитой тоже можно, но не обязательно).
По поводу компьютерных систем, в частности навигационных станций, — тут надо чётко различать границы ответственности. Одно дело, если судовладелец покупает у разработчика ЭКНИС только софт и самостоятельно ставит на свой компьютер, — тут он сам себе буратино. Другое дело, когда мостиковая система поставляется как готовый комплекс в опечатанном корпусе и общающийся с пользователем в режиме «киоска», то есть без возможности доступа к другим программам и свободного перемещения по файловой системе, — тут ещё могут вмешиваться вопросы сертификации.
Доступность Интернета на судне ещё не означает доступность судовых систем из Интернета. Конечно, бывает и так, что кто-нибудь торчит глобальным IP-адресом во внешний мир и не использует межсетевые экраны (о чём свидетельствует комментарий shanker), но здесь нет ничего специфичного для морской отрасли — проблема-то общечеловеческая.
Корректная работа ЭКНИС очень важна, разумеется, но нарушение её работы не должно приводить к катастрофам. Во-первых, в качестве резервного средства много где ещё остаются бумажные карты. Во-вторых, любое сколь-нибудь серьёзное судно (а только такие суда имеют право на безбумажный «воркфлоу», потому что только у них есть деньги на настоящую сертифицированную ЭКНИС) обязательно оснащено радаром и эхолотом, а то и несколькими их видами сразу, — одновременная поломка всего этого маловероятна.
Возможность подделки или уничтожения данных «чёрного ящика» — это нехорошо, да. Но надо отдавать себе отчёт, что если у злоумышленника (которым может быть сам судовладелец или судоводитель) есть физический доступ к объекту интереса — этот объект заведомо подвержен компрометации. Решение очевидно: хранить данные у независимой стороны, — например, отправляя сводку по спутниковому каналу 1-2 раза в минуту (или реже, если этого будет достаточно).
Глушение и подделка сигналов GPS/DGPS, как и AIS, — ну а какой радиосигнал нельзя заглушить? Что до аутентификации навигационных спутников для широкой публики, то над этим вроде ещё только работают, — как можно ожидать решения этой проблемы со стороны производителей трекеров? (Незащищённая передача по наземным каналам — другой вопрос.)
Что осталось за кадром. Если уж упомянули ЭКНИС, то неплохо бы провести анализ того, насколько эти системы защищены от подделки, разрушения и хищения информации в принципе (то есть без учёта непреднамеренных уязвимостей). Например, насколько реально подсунуть в ту или иную систему какие-нибудь поддельные карты вместо настоящих или в дополнение к ним, или повысить статус «неофициальных» карт до «официальных» (официальные карты выпускаются только головными гидрографическими агентствами государств, все остальные карты на их основе — неофициальные; серьёзные суда обязаны использовать только официальные карты). Насколько легко обойти защиту от копирования — перенести приобретённые карты на другое судно с такой же ЭКНИС, или импортировать карты, лицензия на которые не покупалась или истекла (для больших судов такое «пиратство» может не иметь смысла, если инспекторы контролируют их картографическое обеспечение по фактическим отчётам от продавцов). Ситуация тут примерно такая же, как с АИС, — фундамент систем управления правами закладывался в дремучие годы, когда понятия о криптографической стойкости были другие, и специалистов в этой сфере было мало.
Также осталось за кадром, что в дополнение к AIS сейчас существует LRIT (long-range identification and tracking) с двусторонним обменом информацией через спутниковые каналы. Интересно было бы знать, как там дела обстоят с защищённостью.
И самый поучительный момент — на реальных примерах показать, как все эти меры безопасности могут разбиваться о человеческий фактор.
Насчёт автоматической сборки мусора — тут мне сложно даже предположения строить; постараюсь провентилировать этот вопрос, если/когда дело дойдёт до написания отдельной статьи о технологии защищённого исполнения (по идее, у меня она первая на очереди).
Школьное образование закладывает основы. Нас в своё время на уроках по предмету «Основы информатики и вычислительной техники» учили именно основам — что такое циклы и ветвления, функции и переменные, булева алгебра, как нарисовать блок-схему алгоритма. Эти знания не потеряют своей актуальности никогда, даже если компьютеры станут квантовыми, не говоря уже о том, какая операционная система или какой язык программирования будет в тренде в тот или иной момент времени.
Нас в школе не учили пользоваться конкретными программными продуктами. Разумеется, программы писались на реальных языках, и поэтому синтаксис, конечно, изучался — но смысл был не в том, чтобы овладеть каким-то конкретным языком, а в том, чтобы опробовать все те же общие концепции. А вот в институте, напротив, мне не очень повезло, и курсы функционального и логического программирования, например, свелись к тупому изучению Лиспа и Пролога — настолько приземлённому, что даже я так и не понял, в чём фишка этих парадигм и чем они отличаются от традиционного императивного стиля. Про курсы Паскаля, Си и C++, которые в расписании тоже как-то красиво назывались, я уж вообще молчу. Это было именно «ремесленное» изучение, место которому скорее в ПТУ, — как раз то, о чём вы говорите:
сегоднявчера этот Паскаль или FoxPro на коне, а завтра о них уже никто не помнит, и с трудом зазубренные студентом накануне экзамена названия функций нужны чуть менее, чем вообще нигде.Но возвращаясь к операционным системам. Пользованию DOS или NC нас тогда тоже никто не учил, просто показали более-менее, куда тыкать — и этого было достаточно, потому что учить там действительно особо нечему. А вот то, что Linux обошли вниманием не только в школе, но и в институте, — это серьёзное упущение. Ведь смысл изучения *nix (именно Unix-семейства в целом) на академическом уровне — не в том, какой дистрибутив выбрать, какую команду применить для запуска текстового редактора и какой последовательностью клавиш выйти из этого редактора, а в понимании фундаментальных концепций, на которых всё строится. Простор для изучения там необъятный: при желании, можно для любой технической (околокомпьютерной) специальности найти свои темы, в которые следует углубиться дополнительно.
Насколько я понимаю, сейчас в школах учат запускать Windows и набирать тексты в Word. При таком подходе, даже если заменить эти продукты на Linux и OpenOffice соответственно, толку не прибавится ни капельки. Учить в школе и институте надо не тому, что актуально, а тому, что никогда потеряет своей актуальности в принципе.
А вот может ли на судне обеспечения какое-то оборудование считаться «вооружением» — это хороший вопрос. Даже если там установлена аппаратура государственного опознавания, радиолокационная станция, засекречивающая аппаратура связи — это всё ещё «вооружение» или уже нет?