dxdt.blog: занимательный интернет-журнал

Телескопы позволяют следить за звёздами и открывать новые планеты (вне солнечной системы). Это, так сказать, фундаментальная роль. А есть и вполне прикладные, например, работа в составе оптических систем наведения.

Как известно, малозаметные самолёты “Стелс”, например, F-22 Raptor, вполне себе неплохо заметны “визуально” и в видимом диапазоне длин волн, и в ИК. А поэтому оптическая станция с хорошим компактным телескопом, установленная, например, на истребителе, может разглядеть F-22 с большого расстояния.

Понятно, что телескоп в такой станции может довольно быстро осуществлять “сканирование пространства”, а автоматическая система анализа изображения может самостоятельно (и тоже быстро) обнаруживать цели. При этом, если речь идёт о ночном времени, то в ИК-диапазоне тот же F-22 обязательно заметен, вопрос лишь в детекторе, в возможностях по охлаждению приёмной матрицы.

Понятно, с наблюдением возникнут проблемы: облака, атмосферные искажения и т.п. Кроме того, гарантированы трудности с определением координат цели, так как сложно вычислить расстояние. В последнем случае, впрочем, поможет наблюдение с нескольких истребителей, обменивающихся между собой информацией о целях в реальном времени. При этом оптический канал должен работать вместе с РЛС: например, если удалось что-то заметить в данном направлении, то можно туда более тщательно “посветить” радаром, увеличив его чувствительность.

Так что оптические системы развиваются бурно.

“Мастерхост” со своими “иными” панелями управления – кладезь “радостей” для юзабилиста. Я как-то писал уже про исключительно оригинальный способ предоставлять доступ к логам сервера, которого придерживается “Мастерхост”: десяток кликов – и несвежие логи в вашем браузере.

При этом вся остальная, вроде бы вполне очевидная, функциональность хостинга и доменов реализована в “Мастерхосте”, мягко говоря, “не прямым способом”. Отчего – непонятно. Когда исправят – не ясно. Возможно, конечно, что это мои чисто “субъективные наблюдения”, но, с другой стороны, очень уж они показательные.

Например, в “Мастерхост” до сих пор нельзя через SSH удалить на хостинге файлы, созданные сервером из PHP. То есть если PHP-шная CMS создала какие-то файлы во время своей работы, то удалить их “очевидным образом”, через SFTP, не получается. Нужно устанавливать на хостинг какой-нибудь файл-менеджер (PHP) и чистить дисковое пространство с помощью браузера.

Управление доменами также реализовано непонятным образом: ой как не просто найти способ сменить NS-ы, скажем.

При этом большая часть функциональности “Панели управления”, насколько удалось разобраться в этой “иной логике”, собрана в некое “Древо услуг”, где есть и список доменов, привязанных (?) к хостингу. Если кликнуть на имя домена, то вместо ожидаемого интерфейса по управлению собственно доменом возникает весьма странная страница. На ней, например, есть список, заявленный как содержащий “все характеристики домена”. При этом среди “характеристик” обозначены различные CGI-параметры, возможности по установке ПО (!), путь к каталогу для HTML-файлов и тому подобные вещи. Какое отношение эти серверные настройки имеют к домену – не понятно. Из как-то связанных с DNS параметров упоминаются только синонимы домена – и всё, несмотря на заявленные “все характеристики”. Это кошмар.

С целью экономии текстовых символов, не стану уже писать о том, как продлеваются услуги “Мастерхоста” – там прослеживается тот же подход, который выливается в посещение “сайта-магазина” и многократные клики по страничкам.

В общем, пользоваться “Мастерхостом” крайне неудобно. И вообще ничего не меняется уже несколько лет.

По ссылке – подборка космических фотографий ураганов. Вот таких вот, например:

Между тем, Northrop Grumman на днях досталось ещё как минимум $5 млрд на продолжение строительства новейшего атомного авианосца Джеральд Форд (Gerald R. Ford). В принципе, “Форд” готовится на замену “Энтерпрайзу” (самый старый атомный авианосец ВМС США), то есть введение в строй этого нового авианосца не увеличит общее число авианосцев на вооружении.

Но тут нужно иметь в виду, что “Форд” скорее всего будет существенно превосходить “Энтерпрайз” “по военной мощи” – и по типам самолётов, и по их возможностям. Кроме того, на “Форде” должна появиться новая энергетическая установка, которая, как обещают, обеспечит большое количество доступной электроэнергии на борту.

(По клику – схема от “Нортропа с Грумманом” в большом разрешении.)

А электроэнергия – это, конечно, электрокатапульты, которые лучше паровых, потому что быстрее и надёжнее. То есть появляется возможность быстро запускать множество беспилотников. Понятно, что беспилотник проще подготовить к старту: собственно он, беспилотник, всегда готов. Кроме того, беспилотники можно закидывать в воздух с большой перегрузкой один за одним, во все стороны. Чтобы организовать такой конвейер, требуется много электричества. Ну и вообще электрические системы более гибкие, в смысле последующего развития.

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

Кстати, Штатовская военная промышленность сейчас выпускает вполне серьёзные корабли по нескольку штук в год. (Грубо говоря, за год на воду спускают флот, сделавший бы честь многим современным морским державам.) Но, впрочем, авианосцы Штаты пока так быстро строить не научились. “Форд” ожидают в 2015 (не так уж и долго, с другой стороны).

Небольшой оффтопик: заметка с пользовательской инструкцией к “оранжевой гибкой штуке” из сувениров “Ру-центра” в корпоративном блоге.

В продолжение недавней записки про “Касперских” – такой продукт, как Nod32 Smart Security, оказался весьма неплох. Удобный интерфейс, понятная логика. При этом по уровню замедления компьютера – “Касперские” даже и близко не стояли, Nod32 ощутимо быстрее. Рекомендую переходить.

АРМС-ТАСС пишет:

Объединенная авиастроительная корпорация планирует произвести в 2008-2012 годах 434 самолета из которых 236 судов – в рамках проекта “Сухой Суперджет”.

Учитывая, что 2008 год уже практически закончился, то получается 434/4 ~ 108 самолётов в год. Такие вот немалые планы.

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

Блоги и СМИ жужжат о том, что завтра официально стартует LHC – Большой Адронный Коллайдер. И, типа, Землю ждёт большая и очень чОрная дыра. Между тем, дата запуска столь сложного устройства – довольно условный момент. Это ж вам не воздушный шарик полетел. Можно было назначить такой датой некоторое уже случившееся событие на LHC (установка детекторов, инженерные тесты и т.п.). Выбрали 10 сентября и некоторый “первый пучок”.

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

С другой стороны, конечно, можно считать, что на “первом пуске” кто-то “нажмёт не на тот рычаг” и тут оно “как жахнет!”. Обычно так происходит в кинофильмах. Но в реальности, вряд ли всё так же просто, как в кино. Так что нужно сдвинуть срок Конца.

А вообще, про LHC нужно читать в проекте на “Элементах”, который ведёт Игорь Иванов. Или в блоге Игоря.

(Фото: interactions.org)

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

Что тут нужно иметь в виду конечному потребителю, не желающему стать лёгкой добычей маркетологов? Оказывается, достаточно составить хоть и весьма общее, но строгое представление об этих самых вопросах безопасности и их связи с CMS.

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

При составлении собственного представления о безопасности использования конкретной CMS нужно учитывать её отношения с уязвимостями. Тут есть свои важные моменты. Например, то, что сайты под некоторой CMS “Имярек” “за отчётный период” не были взломаны, никоим образом не означает, что “Имярек” сколь-нибудь надёжна и безопасна. Почему? Потому что отсутствие взломов сайтов ничего нам не говорит о безопасности CMS.

Понятно, что сайты под “Имярек” могли быть просто не интересны хакерам. Понятно, что внутри CMS “Имярек” может присутствовать шикарная уязвимость, которую обнаружат завтра. А послезавтра для этой уязвимости хакерская группа напишет бота, и через два дня все сайты под “Имярек” будут взломаны в одном потоке, автоматически. То есть оценить безопасность “Имярека” на основании “полного отсутствия взломов” – невозможно. А если нельзя оценить безопасность, то нельзя и прогнозировать риски.

И если отсутствие сведений о взломах не позволяет оценить безопасность, то информация об успешно залатанных уязвимостях (в том числе, что важно, использованных на практике для взломов) позволяет приступить к оценке безопасности CMS. Такой “парадокс”. Ведь если уязвимости обнаруживают, используют и латают, то это уже свидетельствует, по крайней мере, о том, что кто-то занимается аудитом безопасности данной CMS (хоть бы и хакеры), что CMS поработала в условиях “интереса взломщиков” и что CMS развивается. Конечно, плохо, если новые критические уязвимости обнаруживаются в CMS по нескольку штук в месяц, но ещё хуже, если об уязвимостях вообще нет сведений.

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

Есть расхожее заблуждение, что можно “вслепую” использовать уникальную “проприетарную CMS”, разработанную специально для данного сайта небольшой дизайн-студией. Мол, “секретность” и “уникальность” внутреннего устройства такой CMS обеспечивает безопасность. В реальности же разработчики подобной CMS обычно наступают на все широко известные в кругах специалистов по взлому (и по безопасности) грабли, допуская шаблонные ошибки в архитектуре продукта. Эти самые шаблонные ошибки и станут отличным фундаментом для проведения атак даже без изучения исходного кода. Мало того, секретность исходного кода вряд ли можно обеспечить на практике: при малейшей необходимости исходники утекут. Есть много путей для такой утечки: “через хостинг”, через дыры в других программных системах, после “шаблонного взлома”. Или, скажем, исходники просто распространит создатель продукта. Главное правило таково: секретность исходного кода вообще  не добавляет безопасности системе.

Можно предположить, что CMS с открытым исходным кодом сильно безопаснее. Однако это не так. Действительно, открытый код доступен для изучения всем и вся. Вопрос тут лишь в том, как оценить квалификацию специалистов, изучавших этот код. Одно верно: сама по себе открытость исходного кода не может снижать безопасность CMS.

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

Часто приходится слышать, что коммерческие CMS якобы более безопасные, так как в коммерческих компаниях дорожат имиджем и строго следят за безопасностью. Это неверное обоснование. Да, ничто не мешает коммерческой компании делать безопасный продукт и нанимать специалистов-архитекторов ПО высокой квалификации. Однако на практике коммерческие компании старательно ограждают себя условиями лицензирования от ответственности и используют низкоквалифицированных программистов (а архитекторов не используют вовсе), потому что такое поведение позволяет максимизировать прибыль при обычно небольшом числе инсталляций коммерческой CMS. Бесплатные CMS также имеют свой имидж, которым дорожат лидеры групп разработчиков. И при этом нет никаких оснований считать, что те же программисты, приложившие руку к той или иной бесплатной CMS, не работают в коммерческих компаниях над платными продуктами.

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

Эта заметка – начало серии записок про выбор CMS и про безопасность CMS. Продолжение – в следующий раз. Кстати, в продолжении: нужно ли выбирать распространённую CMS? Платная или бесплатная? Что со “стоимостью владения”? и всякие другие интересные моменты.

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

Например, Штаты опасаются небольших, недорогих, но выполненных на современном уровне подводных лодок, которые могли бы оказаться у тех же самых “вероятных противников” из числа неразвитых в военно-техническом отношении стран.

(Германская подводная лодка времён Второй Мировой)

Речь не о сложных, технологически продвинутых, субмаринах, а о простых дизель-электрических “посудинах”, современность которых определяется применением прогрессивных технологий производства и проектирования, снижающих стоимость и требования по обслуживанию. Единственное важное проявление “хайтека” в такой лодке – меры (не самые прогрессивные, но эффективные) по снижению заметности аппарата.

Простая в эксплуатации конструкция, отсутствие разнообразных сложных систем на борту – всё это позволяет применять лодку не слишком хорошо обученным морякам, а также обслуживать флот таких лодок самыми элементарными техническими средствами. Это ключевые моменты.

Понятно, что лодки по заказу строит и ставит в строй технически продвинутая “третья сторона”. Современный опыт строительства подводных лодок используется “третьей стороной” для того, чтобы создать надёжную, по возможности малозаметную, подводную лодку с большим ресурсом. Создать такой аппарат реально: прогресс тут огромный и в средствах проектирования, и в доступных конструкционных материалах.

Почему Штаты опасаются таких лодок? Потому что при всём богатстве технических средств штатовской разведки обнаруживать и сопровождать небольшую подводную лодку гораздо труднее, чем, скажем, близкий по размерам надводный корабль (или подводный крейсер). При этом подобная лодка может привезти противокорабельную крылатую ракету, стартующую из торпедного аппарата, а может скрытно поставить современные подводные мины “в неожиданных местах”. Более того, небольшая подводная лодка может создавать угрозу безопасности для транспортных судов, обеспечивающих перемещение военных (или “околовоенных”) грузов (можно просто заблокировать некоторые судоходные пути).

Понятно, что с подобными угрозами Штаты умеют бороться. Однако, во-первых, наработанные методы хороши против больших субмарин, а малую и правильно сконструированную – обнаружить сложнее. Во-вторых, построение защиты потребует массового привлечения дополнительных сил и средств, сильно отличающихся от тех, которые годятся для борьбы с надводным флотом. Рост сложности операций Штатам прямо не выгоден.

При этом со стороны противника требуется лишь поддержание боеспособности небольшого флота подводных лодок, которые уже конструктивно выполнены так, чтобы требовать минимума внимания и минимума технического оснащения и грамотности.

Продолжение – в третьей части.

(Часть 1)