Краткое содержание предыдущих серий: концептуальная Власть — это не пропаганда, и не образование.
Это — рецензирование и утверждение (но ни в коем случае не (!) разработка) программ (начиная с образовательной) и стандартов. Не обязательно официально утверждённых, для большинства ситуаций достаточно стандартов де-факто (проблеме которых и посвящена эта статья).
Ну и распределение ресурсов. В условиях победы денежного тоталитаризма — финансирования проектов.
В этой статье отмечу одну из технических проекций концептуальной власти, обеспечивающей продажи главного продукта фирмы майкросовт — ОС Windows®. Распространённость которой в статусе стандарта де-факто приносит далеко не только деньги правильным людям.
Именно поэтому нельзя жертвам (потребителям экспортируемых технологий) так просто взять и соскочить с иглы.
Для правильного понимания статьи необходим навык применения знания принципа наименьших.
Эпиграфом процитирую коньспирологические наблюдения (© Пепелац):
«… Только мелкомягкий всё нормально кажет. Это жжж неспроста. Кому-то майкрософт подсунул бабла (пессимистический вариант) или руки у кого-то кривые (реальный вариант)…»
А теперь — можно переходить к пространному, но необходимому предисловию:
С точки зрения эксплуатации одной из значимых особенностей сервера является то, что живые пользователи на нём появляются не каждый месяц. В зависимости от качества/полноты проработки решения удалённого доступа и культуры персонала, занимающегося сопровождением, потребности в доступе к физической консоли (монитор, клавиатура, сейчас уже практически стандартно — манипулятор типа «мышь») может не возникать годами.
А это (монитор/клавиатура/мышь) — не только деньги (ВВП, ату его!), но и место для размещения и доступа. Что, в ситуации, когда серверов много (хотя бы десятки, не говоря о сотнях и больше) превращается в проблему.
Вопрос связи доступа к физической консоли с информационной безопасностью пока просто отмечаю, без проработки.
Задача стандартная и давно проработанная. Первоначальное решение — концентратор (KVM — keyboard, video, mouse switch) позволяющий подключать одно или несколько (НЯП в типовой конфигурации до четырёх) рабочих мест к любому из серверов (в типовой конфигурации 16-32 порта, иногда с возможностью расширения).
Проблему полноты решения задачи в части проработки периферийных ветвей графа зависимостей (феерический пример единственного освоенного механизма авторизации, особенно фееричного в ситуации, когда в среднуюю частоту использования вкладывается несколько положенных по регламенту замен пароля) опять же только отмечаю.
Следующим естественным шагом, не побоюсь этого слова, «прогресса» была эмуляция физической консоли средствами втыкаемого повсюду web-интерфейса (благодаря чему браузеры последнее время так разжырели).
И венцом — появление экономичных (в смысле занимаемого места) систем от брендов, ориентированных на использование в первую очередь виртуального интерфейса. Естественно с оптимизацией под квалификацию эффективно-управленцев, принимающих решение о выделении финансирования. То есть никаких изысков сверх простого, понятного и доступного даже этой категории парольного механизма авторизации.
Здесь нужно сделать ещё одно небольное отступление на тему клиентского ПО, для случая web-интерфейса — браузера.
Тенденция сокращения цикла разработки затрагивает всех (кстати, годный стендовый пример для верификации тезисов о построении действующей модели коммунизма в отдельно взятой стране в условиях включения в мировую торговлю на чажих условиях).
В Firefox переход произошёл начиная с четвёртой версии.
В настоящее время, с приходом гугля наблюдается тенденция к зачистке зоопарка форматов программных модулей (плагинов) браузеров в пользу угадайте кого. На практике это означает, что Firefox ESR 52 заявлен последним поддерживающим родной (Netscape, NPAPI) формат расширений. Который за годы проприетарщики таки освоили.
Теперь можно излагать и суть статьи, укладывающуюся буквально в пару компактных абзацев:
На любые вопросы про запуск виртуальной консоли через java (есть бинарные сборки под GNU/Linux (из родных проприетарных бинарников под *BSD мне попадались только, не к ночи будь помянуты, поделия касперского, но на то есть эмулятор, к чему пришли уже даже мелкомягкие), есть ограниченно-работоспособный, но для данной задачи достаточный свободный форк) профессионалы ТП (Технической Поддержки) отвечают: «используйте Infernet Exploder, с ним проблем нет».
Чем автоматически, тонко и негласно продвигают востребованнейший нашими залужными «партнёрами» «стандарт де-факто» (надеюсь, на АШ все помнят мораль из приключений ИЯП?).
Такая вот печальная иллюстрация к констатации принципа наименьших:
Практически в любом импотозамещающем проекте остаётся 1-5% компонентов или элементов, которые не могут быть замещены в разумное время и за разумные деньги.
В качестве лирического отступления по вопросу сельского хозяйства (обеспечение семенами) отмечу, что если обеспечение товарными семенами с помощьб реально-рыночных механизмов практически монополизировано нашими демократическими «партнёрами», то издержки на работы по сохранению культур (которые на самом Западе давным-давно утрачены) радостно делегированы… нам же. То есть задача выковыривания встроившегося паразита-посредника вполне решаема.
Пишу эту статью исключительно потому, что в коммерческой пропаганде подобные нюансы практической реализуемости старательно ретушируются.
Комментарии
Не вижу тут именно новостей о импортозамещении, статья посвящена размышлениям.
Заголовок крайне плохой, так как неправильно информирует о содержимом.
Возможно я перестарался с пояснениями ключевых вопросов статьи, но она посвящена на «размышлениям», а описанию закладок… в лучшем случае затрудняющих, а по задумке авторов, полагаю, и вовсе блокирующих возможность полного отказа от одного из важнейших продуктов технологического экспорта.
Причём НЯП данный аспект проблемы ни в одной из аналитических статей посвящённых импортозамещению и тем более — победных реляциях не упоминается.
Заголовок возможно не очень удачный.
Однако в первом приближении суть статьи сводится к грустному сарказму, который вполне соответствует заголовку.
Понятие "новости", особенно на АШ, где их много, имеет иной смысл, чем использован здесь.
так какие проблемы, пишем "Старости импортозамещения...." :-)
Тогда уж «окаменелости».
Впрочем, эта тенденция свойственна проприетарной разработке вообще.
Хотя с другой стороны выбор направления движения… далеко не всегда обременён свойством адекватности.
«окаменелости» - тоже вариант.
а вот хде окаменелостный заголовок? :-) ждемс.
большое некапиталистическое спасибо. :-)
Но вообще-то, строго говоря, ответ вида «жаба усё, используйте ослика» оказался именно что «новостью».
*Реальной* и неприятной.
С учётом того факта, что этой осенью ожидается EOL (EOL: end of life) ESR 52, а разработчики единственной альтернативы IE (жабы), по крайней мере по словам профессионалов ТП, поддержкой нового формата плагинов не озаботились — это… напоминание можно интерпретировать и как новость.
Или неизбежное наступление осени (с сопутствующими событиями) новостью не является?
Хотя данная тенденция (хроническая склонность проприетарщиков к отставанию, те же поделия касперского для Enterprise Linux 7 тому наглядным примером) не нова и не оригинальна.
Не специалист, но затруднит ли Вас пояснить данный термин?
Объяснять своими словами это долго, да и незачем - уже есть объяснения по ключам "дистрибутив линукс", "portage", "система управления пакетами"
Не обязательно. Portage — не единственная реализация. Не говоря о системах, не просто не соответствующих стандарту, но даже не ставящих такой цели.
Можно было просто послать на три буквы (изучать app-doc/pms). Но я всё же соберусь сочинить развёрнутый ответ.
Да. Просто сказал те ключи, которые в голову пришли :)
Можно, а с учётом того, что в той или иной степени оно затрагивает всех — и нужно.
Вопрос насколько понятно получится при вмещении всех необходимых понятий.
И насколько при этом совместимо с пониманием на основаии стандартного комплекса опыта.
«Дистрибутив» — понятие, пошедшее из мира Свободного Программного Обеспечения (СПО). Обозначает программный комплекс (совокупность системного и прикладного ПО), построенный по некоторым фиксированным (хоть и эволюционирующим и не всегда в полной степени формализованным) принципам.
Применению к миру ППО (Проприетарного Программного Обеспечения) препятствует тенденция к *продаже* отдельно системного ПО, отдельно — каждого из элементов прикладного.
Тенденция усугубляется практической смертью традиции *правильной* реализации ППО для стандартизованной платформы (говорим POSIX¸ подразумеваем Unix®, в Windows поддержка стандартов есть, но в ограниченном объёме и сувоеобразной реализации (памфлет про «то же самое, только иначе» помнишь?).
В мире СПО принято разделение разработки на два этапа: собственно разработка ПО (написание кода) и интеграция ПО в дистрибутив.
Первым следствием проприетарной модели разработки (товарное производство и необходимость реализации инструментов, стимулирующих *приобретение*), помимо реализации целого ряда откровенно паразитных функций (тоже труд, оплачиваемый) явилась разработка практически каждым… продавцом собственной процедуры установки.
И смещение приоритетов: если в базисе СПО можно было делать акцент на *правильности*, то в мире товарного ПО на первом месте шла *работоспособность*. Что преопределило популярность статических моделей включения библиотек (с неизбежными следствиями для безопасности системы).
Вторым следствием явился бардак в системе, порождённый зоопарком подходов к разработке и качеством их реализации (кто в лес, кто по дрова). Породивший закономерную коллизию интересов пользователя (зафиксировать рабочую конфигурацию) с интересами разработчика (обновление — это не только ценный мех, то есть платёж за upgrade, но и упрощение задачи сопровождения). Впрочем, процедура обновления аналогично процедуре установки как правило не предусматривала возможности полноценной автоматизации (хотя Мечта об автоматическом списании оплаты жила и получила-таки своё воплощение в Window$ 10).
Ситуация усугублялась склонностью разработчиков к реализации по аналогичным принципам систем автоматического обновления (не мытьём, так катаньем).
Вместе с п.1 — практически достаточные основания для существования жизнеспособной экосистемы вредоносного ПО (вирусы и пр.).
Потому что есть лемма из «Главного Правила»: *никто* (!!!) не должен иметь возможности создания/изменения/удаления *системных* файлов, кроме приказчика пакетов (в значительной степени — «синоним системы управления ПО»).
Реальные пользователи (включая администратора) могут создавать/изменять файлы *только* в своём домашнем каталоге, с ограничениями — в /tmp и /var, администратор (root) также в /etc. Особняком в некоторых дистрибутивах — /boot, /usr/src и /lib/modules.
Идиллия несколько нарушается рядом разработчиков ППО, вынужденных поддерживать свободные платформы, но закономерно… экономящих на проработке вопроса правильности реализации и попросту переносящих повадки выньдоуз-погромистов.
Некритическое выполнение предписаний которых приводит к появлению в дистрибутивах СПО того же бардака, что и в Window$ (необходимость отслеживания и какого-никакого контроля за которым создаёт спрос на главного вируса, известного под торговой маркой «антивирусного ПО»).
Справедливости ради: качество решения задачи (управления ПО) некоторыми архаическими (и выбраными коммерческими вендорами) системами ПО в GNU/Linux тоже… оставляет желать лучшего. Но это уже другая история.
А воз и ныне там. Свежие впечатления на тему: